The Vishwaas AI Data Trust Model.

The human whose personal data the Data Fiduciary processes. The hub at the centre of every relationship in the model.

The kind of Data Principal the fiduciary deals with — Customer, Employee, Patient, Loan Applicant. Defines which attributes apply and which notices reach which audience.

A single field of personal data — email, phone, Aadhaar, salary, blood group. Bound to one or more DP Profiles with sensitivity, retention, and encryption metadata.

A third-party system that holds or processes DP data — CRM, HRIS, e-commerce platform, analytics warehouse. The carrier for inbound + outbound bindings.

Connectors on a Processing System. Source Bindings fetch DP data IN; Downstream Bindings propagate consent decisions, attribute changes, and erasures OUT.

The legal entity that operates a Processing System on the Fiduciary's behalf under a DPA. Carries cross-border, DPA expiry, and sub-processor disclosure.

The reason a fiduciary touches personal data — "Marketing emails", "Salary disbursement", "Order delivery". Carries lawful basis (§6 consent / §7 legitimate use), attributes, and retention.

The multilingual privacy notice the DP sees before granting consent. Profile-scoped, hash-anchored per language, gated by Rule 3 readiness at publish.

Append-only, SHA-256-chained, RSA-signed proof of a grant / withdrawal / modification. Anchored to the exact notice version & language the DP saw.

Bulk consent collection — targets a DP Profile audience, attaches an active Notice, dispatches deep-link magic tokens, and tracks delivery.

The tenant's single-row DPDP §5(1) identity — legal entity, registered address, DPO, grievance officer, SDF/DPBI status. The voice of the fiduciary in every notice.

The cryptographic backbone — every consent record's hash feeds the next chain hash. One mutation anywhere breaks the chain everywhere downstream.

Most fiduciaries' largest profile. Marketing emails · order tracking · loyalty program · cookie analytics · pull from CRM.

Internal HR scope. Salary disbursement · provident fund filing · attendance · health insurance.

Regulated sub-population. CIBIL fetch · KYC verification · Aadhaar masking · disbursement.

If activity's lawful basis = legitimate_use, refuse. §7 activities don't take consent; recording one = fraudulent paper trail. (activity_is_legitimate_use)

Does this DP belong to activity's DP Profile? Customer-only DP cannot consent to Employee-scope activity. (dp_not_in_profile)

Request body must carry noticeVersionId + noticeContentHash (64-hex) + language. No anchor = no proof of what DP saw. (notice_version_required)

Compare submitted hash vs the notice version content hash for that language. Stale or tampered notice = refuse. (notice_anchor_mismatch)

Every required processing-activity attribute must be in the granted attribute bindings. Optional attributes honoured but not enforced. (required_attribute_missing)

Referenced notice must be in status active. Archived/draft versions cannot anchor consent. (notice_not_active)

tenant: acme-corp — 7c14db90c3e8…f25b

CUST-001 · MKT_EMAILS · granted — a3f9e1b2c4d7…081a

CUST-002 · ORDER_TRACK · granted — be8a73d04f2c…91e7

CUST-001 · MKT_EMAILS · withdrawn — d50c1ff84a6e…3b29

CUST-003 · NEWSLETTER · granted — f29b045ad1c6…7c40

Owns DPDP outcomes end-to-end. Approves notices, breach assessments, DPIAs.

Configures activities, attributes, notices day-to-day. Closest to the model.

Reviews notice copy, DPA contracts, retention rules. Final sign-off on legal exposure.

Owns encryption keys, audit chain integrity, breach response, CERT-In.

Connects Processing Systems, configures bindings, manages webhooks & SDK keys.

Marketing / HR / Operations lead who defines why data is needed.

Fiduciary Profile · Profiles · roles.

Attributes · rationales · §6/§7 split.

Source + Downstream bindings · Processors.

Multilingual · Rule 3 · launch.

Chain · audits · DPR · breach drills.