The Deontic Architecture®
Personal information is well protected while it is stored and while it crosses a network. It is poorly protected once a system computes on it and produces something new. A credit score, a risk flag, an eligibility result or a model trained on a person's records is a fact about that person that was never collected from them, so the privacy duties on the original record do not follow it. A person can have the address on file corrected and still have no way to contest the score built on the old one.
The Deontic Architecture keeps the duty owed to a person attached to the records that describe them, and to everything derived from those records. It applies to any authoritative record about identifiable people, whether a public body or a private organisation holds it, and to every kind of algorithmic derivation, from a simple scoring rule to a frontier AI model. It adds five constructs to the protections that already exist and replaces none of them:
- Subject Duty Envelope
- Attaches the permitted purposes, legal basis, authority, retention, contestation route and security classification to each piece of data. Anything derived from it inherits them.
- Derivation Ledger
- Records how each derived result was produced and from which sources, so no inference exists without a line back to the duties on its inputs.
- Use-Moment Gate
- Checks the envelope when data is used. When it is uncertain, it refuses and says why. It never proceeds silently and never blocks silently.
- Contestation Locus
- Extends the right to dispute a record to everything derived from it. Correcting a source flags every downstream result for re-derivation.
- Governance Mesh
- Splits authority over privileged actions so no single party can quietly change a purpose, turn off contestation or remove data. Every privileged action is published to a transparency log.
Where a record concerns First Nations, Inuit or Métis individuals, communities or lands, the envelope carries collective authority as a field of its own, and individual consent does not override it. The architecture draws on the OCAP and CARE principles and on UNDRIP, and writes them as requirements a system can be tested against.
What the specification contains
Seven documents: the project charter, the scope and standards foundation, the reference architecture, a model procurement clause, an ontology, taxonomy and crosswalk to the federal instrument set, a review of comparative leading practice, and model business requirements. The procurement clause and the business requirements are written to be lifted straight into a request for proposals or a requirements baseline, with each requirement paired with the test that shows it has been met.
Three conformance levels
- Level 1 Custodial: envelopes present and enforced at access, a ledger of derivations, and contestation of records. Achievable with current technology.
- Level 2 Continuous: adds the gate running in a trusted execution environment, duties carried into derived results, and contestation that reaches them. Depends on confidential computing maturing.
- Level 3 Anti-capture: adds the Governance Mesh with distributed authority. Depends on institutional design as much as on technology.
A buyer can require Level 1 Custodial today and commit to the path beyond it. Conformance is verified against the specification's tests by DSarchitek Inc. and is never self-declared. No system has yet been assessed against any level.
Where adoption costs least
A system that must carry a security classification already needs a metadata scheme for it, and the envelope rides on the same scheme, so both can be assigned in one step at design time. Added after a system is built, the same envelope means a rebuild. An organisation that wants the duty to follow its data should put the requirement into the baseline of the system it has not yet built.