A consent is a typed permission a party has given you: to process their data, to market to them, to share their details with a third party. Opbox holds each one as a first-class record against the party it belongs to, so “did this client consent to marketing, and is that consent still live?” has one provable answer rather than a note in a file. Granting and revoking are governed writes, and every transition is written into the same tamper-evident audit chain as the rest of the work, so the consent register doubles as the evidence that the consent was given, when, and by whom.
What it does
Consent is a state on a party, not a separate system. A consent record is a typed fact bound to a party: a consent:<type> entry (for example consent:marketing or consent:DATA_PROCESSING) whose value carries the status and where the consent came from. The consent type lives in the fact’s key, so you are never limited to a fixed list - any consent your practice needs is just another typed fact on the party. Because it is stored alongside the party’s other compliance facts rather than in a bolt-on store, it reads back the same way every other fact does and inherits the same governance.
Grant and revoke. A consent is either GRANTED or REVOKED. Recording a consent writes a GRANTED state; revoking it writes a REVOKED state over the same fact. Re-granting after a revocation is the same write again, so a consent can be withdrawn and given afresh without ever spawning a duplicate record. Each write is an idempotent upsert, so a double-click or a retried call records the consent once, not twice, and the register always reads back the latest state.
The grant and revoke are the audit trail. Every consent write goes through the kernel’s one front door and lands as a hash-chained audit event, so the moment a consent was granted or withdrawn is the legally-operative record, not a side-effect you have to reconstruct. That chain is exactly what a data-protection request or a regulator asks for: a tamper-evident history of who held what consent and when it changed.
The register, by consent type. The consent records across your parties read back as the consent:<type> facts on each party, and you can drill into a single record to see its type, status, and source. This is the firm-wide view that answers “did this client grant marketing consent, and is it still live” in one read.
It sits on the party record it belongs to. Consent is one facet of the broader stakeholder record. A party (a client, a counterparty, a company, a regulator) carries its core details, its relationships, and its KYC standing, and its consents hang off the same record. So the consent register and the party profile are two views of one source of truth, never two stores you have to keep in step.
How you use it
Record a consent. Open the consent register, name the party and the consent type, and record it. The consent lands as a GRANTED state on that party, attributed to the source, and appears in the register straight away.
Revoke a consent. Open the record and revoke it. The status flips to REVOKED on the same fact, and the revocation is written into the audit chain as the operative moment the consent was withdrawn.
Read the register. List the consents on a party to see each consent:<type> record and its current state. Select a record to see its full detail: type, status, and where it came from.
Prove a consent. Because every grant and revoke is a hash-chained audit event, you can follow the audit feed for a party to produce the exact, ordered, tamper-evident history of its consents - the evidence behind a subject-access request, a marketing-permission query, or a compliance review.
Keep the wider party record current. Add or look up the person or company behind the consent, edit their core details, see how they relate to other parties, and run their KYC review, all on the same stakeholder record the consent attaches to.
The kernel verbs behind it
Each goes through the one front door: permission-checked and audited before it runs. Consent itself is written and read through the fact.* family (a consent is a typed party fact, not a verb of its own); the surrounding stakeholder record is the party.* family.
Recording and reading consent:
fact.set- the single internal writer for a party-bound compliance state; grant or revoke aconsent:<type>fact as an idempotent, audited upsert.fact.list- read the facts on a party (filterable by field key); theconsent:<type>entries are the consent register.
The stakeholder record the consent attaches to:
party.create- add a person or company to the workspace.party.get- read one party record.party.list- list parties, filtered by type, status, or feed (also the firm-wide KYC-expiry register, derived not stored).party.update- edit a party’s core fields (display name, email, and the rest).party.profile- read the full profile, relationship graph, and KYC standing.party.facet.set- write a typed facet (partyKyc,partyCorporate,partyEquity,partyPortalPrincipal), encrypted before write for regulated PII.party.kyc.review- the partial KYC re-verify: rewrite the standing fields and derive the expiry on a VERIFIED transition, preserving every encrypted PII facet.party.relationship.list- the company-registers read: directors, shareholders, UBOs, and secretaries with role, share percentage, status, and appointment dates.party.suspend/party.reactivate- move a party between SUSPENDED and ACTIVE, with a reason on the record.party.merge- fold a duplicate party into another.party.archive- retire a party record while keeping its history.
See the full set in the party verb reference and the fact verb reference.