A visual walkthrough of the entities behind every DPDP-defensible consent record — Data Principals, DP Profiles, Attributes, Processing Systems, Source & Downstream Bindings, Processing Activities, Notices, and the cryptographic Chain of Consent that ties them together.
Every DPDP control — notice issuance, consent collection, rights fulfilment, breach notification — resolves to a relationship between these twelve entities. Read the rest of this document as the story of how they connect.
The human whose personal data the Data Fiduciary processes. DPDP §2(j). 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. DPDP §2(k). 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.
A Data Principal is a real human, but a single fiduciary may know them in more than one capacity — Rahul the Customer, Rahul the Employee, Rahul the Loan Applicant. Each capacity reveals different attributes, triggers different processing activities, and carries different consent obligations.
Vishwaas AI resolves these capacities into a single canonical data_principal record — so the same person can be erased once, contacted in their preferred language once, and audited from one place — while still expressing membership in multiple DP Profiles.
_encrypted BYTEA + _hash VARCHAR(64) for indexed lookup without exposing plaintext.A DP Profile is how the fiduciary organises its world. Every Processing Activity is scoped to one profile. Every Notice serves one profile. Every attribute is bound to the profiles where it actually applies.
dp_profile_membershipsMarketing emails · order tracking · loyalty program · cookie analytics · pull from CRM
Salary disbursement · provident fund filing · attendance · health insurance
CIBIL fetch · KYC verification · Aadhaar masking · disbursement
dp_profile_id NOT NULL. Every Privacy Notice carries dp_profile_id NOT NULL. A notice can only include activities from its own profile — enforced by the notice_version_activity_profile_match_check Postgres trigger which raises cross_profile_activity_in_notice. Cross-wiring is a database error, not a runtime check.
An Attribute is a single field — email, phone, aadhaar_number, blood_group, cibil_score. The fiduciary's attribute catalog is the master list of every kind of fact it might ever hold about a person.
Each attribute is bound to a DP Profile at the catalog level (a profile-attribute binding) and again to a Processing Activity (a processing-activity attribute) — at which point a ≥ 30-character necessity rationale must be written. That rationale is the data-minimisation defence under DPDP §6(1).
always, on_demand, or hidden — controls when the attribute label appears in the portal.Each binding above carries a ≥ 30-char necessity rationale (e.g. "Required to deliver the marketing newsletter to the unique email address the principal registered.") — audit-loggable, surfaced in the activity register, and demanded by the publish-gate Rule 3 check.
A Processing System is any third-party application that holds or operates on DP data — a CRM, an HRIS, an e-commerce platform, an analytics warehouse, FarmRise. Vishwaas AI doesn't replace these systems; it puts a consent-aware membrane around them.
A connector that pulls DP data into Vishwaas AI from the Processing System. Required to make any DP show up in the consent ledger.
Every Source Binding has a processing_system_id NOT NULL and a target dp_profile_id — so ingested rows always know which audience they belong to.
A connector that propagates consent decisions, attribute changes, and erasure operations out of Vishwaas AI to the Processing System — so it always sees the right people in the right state.
GET /consent-status · Redis-cachedconsent_propagation, attribute_value_change, dp_data_removalEvery Downstream Binding serves exactly one DP Profile, so a Marketing Emails withdrawal never accidentally fires at an HRIS that doesn't know about that profile.
propagation_delivery_log. If any downstream call fails, it retries with exponential backoff, then lands in the dead-letter queue for operator action. That is what "real-time compliance" actually means in practice.
A Processing System is the technical artefact (the CRM instance, the SMS gateway, the analytics warehouse). A Data Processor is the legal artefact — the company that operates that system on the fiduciary's behalf under a written Data Processing Agreement. DPDP Act 2023 §2(k).
One Data Processor typically operates several Processing Systems — AWS hosts your storage and your VPC and your queue; SendGrid runs your transactional email and your bulk mail; Razorpay handles payments and invoicing. The DPA covers all of them at once, but cross-border, sub-processor disclosure, and DPA expiry tracking live at the Processor level, not the System level.
ap-south-1 vs us-east-1) and Schedule transferability flags.(In the current codebase the Prisma model is still named vendor for backwards compatibility; the v2.7 rename to data_processors is on the roadmap. The conceptual name "Data Processor" is canonical in every new spec, audit event, and user-facing label.)
Every reason a fiduciary touches DP data — "Marketing Emails", "Salary Disbursement", "Order Fulfillment" — is one row in processing_activities. In v2.6-New, a single row carries two layers: the internal RoPA-style metadata (always populated) and, when the lawful basis is consent, the DP-facing copy the principal will read in the privacy notice.
Both layers are populated. The DP sees a notice, the DP grants, the consent record is appended with notice anchor + content hash + per-language proof. Withdrawal propagates to every Downstream Binding within 5 seconds.
Layer 1 only. The activity lives in the internal RoPA register but appears in no privacy notice. The Section 7 sub-ground enum captures the specific justification: employment_purposes, state_function_subsidy_benefit, legal_obligation, medical_emergency, pandemic_or_disaster_response, and so on.
Acme Corporation collects your email address, full name, and (optionally) mobile number so we can send you our weekly newsletter, product launch announcements, and personalised offers.
content_hash[en]: 8af3e9b2…41c
content_hash[hi]: 2c14db90…7e5
content_hash[ta]: 91a47fee…d63
A Privacy Notice in Vishwaas AI is always scoped to exactly one DP Profile. The Customer notice and the Employee notice are different documents, in different versions, with different attribute scopes, and they cannot accidentally include each other's Processing Activities — the database trigger refuses.
Every version of a notice computes a per-language SHA-256 content hash and stores them in a JSONB map content_hash_by_language. When a DP grants consent in Hindi, the consent record captures the exact Hindi hash they saw — three years later, in court, the fiduciary can prove what document, in what language, on what date.
rule3.entity_name_missing, rule3.activity_MKT_EMAILS_attributes_missing, …) surfaced on the editor right-rail. The system refuses to publish until 100%.
Before a single byte hits consent_records, the service enforces this exact ordered chain. Failing any step rejects the request with a typed error code — and the consent simply doesn't happen.
If the activity's lawful basis is legitimate_use, refuse. §7 activities don't take consent — recording one would create a fraudulent paper trail. Error: activity_is_legitimate_use.
Check dp_profile_memberships — does this Data Principal belong to the activity's DP Profile? If a Customer-only DP tries to consent to an Employee-scope activity, refuse. Error: dp_not_in_profile.
The request body must carry noticeVersionId + noticeContentHash (64-hex) + language. No anchor → no proof of what the DP saw. Error: notice_version_required.
Compare the submitted hash against notice_versions.content_hash_by_language[language]. If they don't match, the DP read a stale or tampered notice — refuse. Error: notice_anchor_mismatch.
Every processing_activity_attribute flagged isRequired must be present in the DP's grantedAttributeBindingIds. Optional attributes are honoured but not enforced. Error: required_attribute_missing.
The referenced notice version must currently be in status active. Archived or draft versions cannot anchor a consent. Error: notice_not_active.
Only when all six pass does appendConsentRecord compute the new record_hash, link to the previous record's chain_hash, sign with the tenant RSA key, and INSERT (no UPDATE — the row is forever).
Every consent record's hash is fed into the next record's chain_hash. Tamper with any historical row and every record after it becomes unverifiable. This is the cryptographic property that converts a database into legal evidence.
JSON.stringify of {tenantId, principalId, purposeId, action, status, timestamp, channel, ipAddress, consentTextSnapshot, noticeContentHash, …}. The legacy JSON key purposeId is intentionally preserved so the chain survives the v2.6 column rename to activityId.SHA-256("VISHWAAS_AI_GENESIS_" + tenant_id).record_hash. Verifiers reproduce the hash, retrieve the tenant public key from the /.well-known endpoint, and validate.consent_records table is physically append-only. Migrations issue REVOKE UPDATE, DELETE ON consent_records FROM crosstrust_app. The application user simply does not possess the privilege to mutate a historical row — even if a developer wrote the code, Postgres would refuse the statement.
One row per tenant in data_fiduciary_profiles consolidates every DPDP §5(1) mandatory contact and identity field — legal entity name, registered address, DPO contact, grievance officer, SDF status, DPBI registration, rights portal URL, withdrawal portal URL, preferred languages, guardian-verification strategy.
This row is read by three high-stakes surfaces: the Settings → Fiduciary Profile editor, the DP-Portal PortalFiduciaryFooter shown on every notice render, and the publish-gate Rule 3 check that refuses incomplete profiles. When the DPO's email rotates, every future notice picks it up automatically — no manual republish required.
BYTEA columns with sibling SHA-256 hashes for indexed lookup.is_sdf mirrors the tenant's flag. SDF tenants must additionally populate dpbi_registration_id.en. Drives which locales are required on every notice.signed_declaration (default), digilocker, govt_id_match, video_kyc, multiple — governs §9 minor-consent flows.Read this from the Data Principal in the centre outward. Each arrow is a foreign-key relationship in the production database; each colour is an entity family; each animated dash shows where data & consent decisions actually flow at runtime.
Same twelve entities — re-explained from the lens of the DPO, Privacy Manager, Legal Officer, CISO, IT Admin, and business owner sitting inside the customer organisation. What problem does it solve? Who owns it day-to-day? What evidence does it produce when the DPBI knocks?
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.
The real people whose data you hold. Before Vishwaas AI, the same person exists as a row in your CRM, a row in HRIS, a row in your loyalty database, a row in your support tool — and you have no idea any of them are the same human.
A bank doesn't talk to a Loan Applicant the way it talks to a Salary Account holder. A hospital doesn't talk to an OPD patient the way it talks to an in-patient. Vishwaas AI codifies these audience classes as DP Profiles — and every notice, every activity, every binding inherits the right scope automatically.
The DPBI's first inspection question will be: "Why do you collect this field?" Today, your defence is verbal. With Vishwaas AI, every attribute bound to an activity carries a ≥ 30-character necessity rationale, written by the Privacy Manager, reviewed by Legal, surfaced in the activity register.
Your Salesforce instance, your Workday tenant, your SendGrid subaccount, your Razorpay merchant. Every system that holds DP data somewhere. Vishwaas AI doesn't replace any of them — it puts a consent-aware membrane around them.
A Source Binding pulls customer data into Vishwaas; a Downstream Binding propagates consent decisions out. Both are configurable in minutes — REST poll, SFTP, CSV upload, push webhook, pull connector, or embedded SDK — and both write delivery proof to the audit log.
Every Processing System is operated by someone — AWS, SendGrid's parent Twilio, Razorpay, Mixpanel. DPDP §2(k) calls them Data Processors and mandates a written agreement. Vishwaas AI tracks the DPA, its expiry, cross-border posture, and sub-processors per Processor — not per System.
"Marketing Emails", "Salary Disbursement", "Order Fulfillment", "CIBIL Pull", "Birthday Gift Despatch". Every reason your organisation touches DP data becomes one row in the activity register. Each row decides its own lawful basis — DPDP §6 (consent) or §7 (legitimate use) — and refuses to mix.
/admin/reports/activities-register · per-activity attribute scope · retention period · last-reviewed date · automatic flag on review-overdue activities.A multilingual privacy notice, drafted in TipTap, gated by Rule 3 readiness, hash-anchored per language. The Privacy Manager drafts; Legal reviews; DPO approves; Vishwaas refuses to activate it until every Rule 3 box ticks green.
Every grant, withdrawal, or modification appends to an immutable hash-chained ledger. Append-only at the database privilege level — even an admin SQL user cannot UPDATE a historical row. The chain is what converts a database from "our records" to legal evidence.
POST /consent/verify-integrity/4217. The system replays the entire chain from genesis to that record, returns {verified: true, signature_valid: true}. The regulator is satisfied. Total elapsed time: 90 seconds.One row in the database. Legal entity name, registered office address, DPO contact, grievance officer contact, SDF status, DPBI registration, rights-portal URL, withdrawal URL, preferred languages, guardian-verification strategy. Read by every privacy notice render.
is_sdf = true, adds the DPBI registration ID. Every future notice render now shows the DPBI contact in the footer. Compliance turnaround: 5 minutes, zero developer effort.