Schema annex: the record structures, as fields
Companion to the model instrument. Each schema below is a field table: a drafter can read it as "what the obligation looks like as data"; an implementer can read it as a starting structure. Deployment status is stated per schema and per field, because the difference between running and specified is exactly the kind of thing this kit exists to make explicit. Three status values recur:
- Running - in production on our systems or a client deployment today, named as they appear
- Canonical - the generalised form this annex proposes
- Specification - designed and published but not yet deployed
Where a mechanism is demonstrated by published, runnable reference code rather than by an in-production deployment, it is marked running reference implementation with the repository named.
Field types use plain names (text, date, link, selection, hash) rather than any platform's vocabulary, so the tables transplant.
Schema 1: Consent grant
Instrument reference: Part 2, sections 7-9. Status: a consent lifecycle record is Running in production; the five-element grant extends it, and the extensions are marked.
| Field | Type | Required | Status | Meaning / instrument element |
|---|---|---|---|---|
| grantor | link (person or organisation) | yes | Running (as participant) |
Who issues the grant |
| grantee | link (organisation) | yes | Canonical | Element (a). Running system holds this implicitly (the operating entity is the grantee); a general grant must name it |
| data_scope | structured text or class list | yes | Running (as activity_scope, partial) |
Element (b): the data or classes covered |
| purpose | text, one per purpose | yes | Running (as activity_scope, conflated with data_scope) |
Element (c). The running field conflates (b) and (c); the canonical form separates them because purpose limitation (s10) cannot be tested against a conflated field |
| period_end | date | yes, or review_interval | Running (expiry_date) |
Element (d) |
| review_interval_days | integer | alternative to period_end | Running (refresh_interval_days) |
Element (d) alternate form; drives refresh prompts |
| revocation_method | text | yes | Canonical | Element (e). Running system implements revocation (below) but does not state the method in the record; s7 requires it stated |
| status | selection: given / active / refresh-due / renewed / withdrawn | yes | Running | Lifecycle state |
| given_date, given_by | date, text | yes | Running | Formation evidence |
| withdrawn_date, withdrawn_reason | date, text | on withdrawal | Running | Revocation evidence (s21) |
| renewal_count, last_renewed_date | integer, date | - | Running | The record as lifecycle object (s9), not collection-time ritual |
Gap statement, plainly: the running record implements the lifecycle (status, refresh, withdrawal, archival) and four of the five elements in some form. The named grantee and the stated revocation method are the two additions the instrument would force; the conflation of data-scope with purpose is the one separation it would force. That a production consent system built independently lands this close to the five elements is evidence the elements are the right five.
Schema 2: Determination record
Instrument reference: Part 5, sections 17-20. Status: the human-determination structure is Running; the paired inferred-result structure is Running on a client deployment (a design-review platform in commercial use); the canonical table generalises both.
| Field | Type | Required | Status | Meaning |
|---|---|---|---|---|
| subject_ref | link | yes | Running | What the determination is about (the checklist item, application, case) |
| result | selection (domain-specific; e.g. pass / fail / pending) | yes | Running | The conclusion |
| author | link (person), captured at adoption | yes | Running (via record ownership + workflow actor) / Canonical (as explicit field) | Section 17. The running system derives the author from the acting user and workflow; the canonical form makes it an explicit, immutable field because derived authorship decays when records are migrated or bulk-edited |
| adopted_at | timestamp | yes | Canonical | The author's act of adoption (s20) as an event, distinct from record creation |
| informed_by | link to inferred result record(s) | where applicable | Running (client deployment) | The join that makes "informed by an inferred result" a queryable fact rather than a sentence |
| response_text, notes | text | - | Running | Reasons, in the author's words |
Paired structure - inferred result (the parallel record, never the same table):
| Field | Type | Required | Status | Meaning |
|---|---|---|---|---|
| subject_ref | link | yes | Running (client deployment) | Same subject the determination will address |
| inferred_conclusion | text / structured | yes | Running (client deployment) | What the model derived - displayed with a distinct visual marker so it cannot be mistaken for a determination (s20) |
| provenance_ref | link to provenance record | yes | Canonical (fields exist; the join is the addition) | Section 18(b): what produced it |
| produced_at | timestamp | yes | Running (client deployment) | - |
| adopted_into | link to determination, set only by an author's act | - | Canonical | The one-way door: an inferred result becomes part of a determination only through adoption, never by default (s20's contravention, as a constraint the database enforces) |
Schema 3: Provenance record
Instrument reference: Part 4, sections 14-16. Status: Running - the table below is the production structure, fields named as deployed; the one class-C field (the signature) is demonstrated by a running reference implementation at git.meanwhile.computer.
| Field | Type | Required | Status | Meaning |
|---|---|---|---|---|
| record_type | selection: summary / entity / source | yes | Running | What kind of provenance claim this is |
| model | text (identifier/version) | yes | Running | The trained model involved (s15 minimum) |
| capability | text (identifier) | at class C | Running | The separable capability component (s15, class C) |
| source_ref | text | - | Running | The input span, document or tool response drawn on |
| captured_value | text | - | Running | What was captured, verbatim |
| data_hash | hash | yes | Running | Integrity: the record can show the captured value is unaltered |
| captured_at | timestamp | yes | Running | - |
| intent_ref | link | - | Running | The request context that occasioned the inference |
| signature | cryptographic signature | at class C | Running ref. impl. | The upgrade from declarative to verifiable (s16): the record signed such that a non-trusting party can check it - the subject of the published capability-licensing research, whose reference implementation runs at git.meanwhile.computer |
Working reference code. A running reference implementation of the licensed-capability mechanism is published at git.meanwhile.computer/meanwhile/research - clone it and check the claims yourself.
Schema 4: Mandate package
Instrument reference: Part 3, sections 11-13. Status: Running reference implementation - the mandate mechanism (grant binding, time-bound decryption, revocation state) runs as published reference code at git.meanwhile.computer; the generalised schema below is the canonical form for adoption.
| Field | Type | Required | Meaning |
|---|---|---|---|
| grant_ref | link to consent grant | yes | The grant this data travels under (s11) |
| payload | encrypted data | yes | The data itself, protected under the grantor's keys at class C (s12) |
| scope_digest | hash of elements (a)-(e) | yes | The grant's terms, resolvable from the package without a round-trip |
| revocation_state | selection: active / advisory-revoked / access-gated / erased | yes | Current state, checkable before any use (s24) |
| window | period | yes | Time-bound decryption: outside the window the payload does not decrypt (design: secure-timestamp bound) |
| access_log_ref | link | for compelled access | Section 25's audit trail |
Reading the four together: schemas 1-3 exist because the pattern was needed for real work before any policy required it; schema 4 exists because the first three make it the obvious next structure. A drafter can cite the tables; an implementer can build from them; a sceptic can note precisely which columns are running and which are proposed, because the annex just told them.
Written with model assistance. Read and edited by a human - though I'm not an editor, so tell me what I've missed: send me a note. Field names marked Running are as deployed; corrections from implementers are the most valuable kind.
Reviewed and checked by the human author: 2026-07-20.