A4. Data model
Status: normative. Document version 1.0-draft-1.
A4.1 Entries and vocabulary
The exact stored/exported entry is defined by entry.json, with complete synthetic examples in protocol.json. Fields include an internal ID and immutable version, partition, domain/key, typed value, semantic kind, provenance, temporal interval, optional overlay, approved rendering, status and origin. Safety and sensitivity come from the trusted vocabulary, never contributor-supplied flags.
context_kind is fact, preference or state, independent of provenance. Facts describe a declared or evidenced condition. Preferences express choices. States describe bounded current circumstances. value_type must match the key definition, and value must pass that key's closed schema. The larger type-name enum reserves future types; it does not admit unregistered keys. The vocabulary specifies types, cardinality, levels, renderers, flags, labels, explanations and per-level examples for every v1 key.
A change creates a new immutable version. Older versions remain history under owner retention policy. active, superseded and archived are stored value statuses; expiry is computed from time, not a status that depends on a worker. Deletion creates a separate non-content tombstone with ID/version/partition/domain/key and deletion time; it carries no value or evidence. A tombstone's version is one more than the last version of the entry it deletes, so no ID and version name both a version and a tombstone, and an earlier version keeps the status it was written with. Record erasure additionally follows owner retention and applicable obligations; retaining a tombstone does not permit retaining the deleted value indefinitely. A partition holds at most 10,000 entries that have not been deleted, which bounds what one read compiles; a write that would add another fails with entry_limit_reached and changes nothing. No agent operation adds an entry: a contribution is acknowledged as a proposal whatever the partition holds (A14), so only the person's own operations, such as accepting a proposal in the first-party app or an import, meet the limit.
A4.2 Provenance
declared means the person entered or explicitly confirmed the exact statement; it requires confirmed_at. observed covers sourced observations/inferences, requires source identity, occurrence and ingestion times, confidence, and a finite validity end no later than 90 days after ingestion. derived names every input ID, version and actual field/level used. attested is reserved for future credential verification and MUST be withheld from v1 recipient disclosure unless the person separately confirms a declared entry.
Source identity is evidence of origin, not truth. Review of a contribution does not automatically relabel it as declared. Preserve source event identity and evidence after confirmation; never disclose that evidence merely because the confirmed preference is shareable.
Special-category and safety-critical keys MUST NOT be observed or inferred. inferable:false is absolute; a domain toggle cannot override it. Imported sensitive suggestions remain protected proposals until exact confirmation in the first-party app. Confidence is not consent.
A4.3 Temporal intervals
Wire instants are UTC RFC 3339 instants with Z. Instants compare by the time they denote, at full fractional precision, not by their bytes: 2026-09-21T00:00:19.9999Z and 2026-09-21T00:00:19.999900000Z are the same instant. Date-only entry is a UI convenience: the UI resolves the selected timezone and daylight-saving ambiguity before storing an instant. A month means the selected local calendar interval, not an assumed number of seconds. Version 1 has no recurrence rule.
Use one provider Clock instant for the entire read transaction. Eligibility is valid_from <= now < valid_until. Null start means no lower bound; null end means no upper bound. Reject equal or reversed finite bounds. A state and every overlay require a finite end. Future entries do not appear early. Manual archive/disablement takes effect on the next read. Entry validity and grant validity are checked independently.
Staleness is informational: confirmed_at older than 365 days, or 90 days for safety-critical keys, sets stale:true. Never infer that a stale allergy has ceased. An expired temporary fact is omitted; any independently eligible standing safety fact remains.
A4.4 Baselines and temporary overlays
An overlay is a separate preference entry with overlay:{target_entry_id,enabled,selected}. The target must be an active baseline in the same partition/domain/key. Version 1 allows overlays only for single-cardinality, non-sensitive, non-safety preferences. The person explicitly enables it; enabling it is separate from making it permanent. Overlay creation or expiry MUST NOT supersede or alter the baseline.
Overlays apply only to the baseline that is eligible and selected for its key at that instant; the overlays of any other baseline are neither disclosed nor considered. Selection counts only the eligible enabled overlays for that baseline: a selection on an overlay that is not eligible under A4.3, or not enabled, neither wins nor counts against another overlay. Among the eligible enabled overlays, one explicitly selected overlay wins. If none of them is selected and exactly one is eligible, that one applies. If several are eligible without one selection, or several of them are marked selected, apply none and use the eligible baseline until the person resolves the conflict. A choice atomically clears competing selections for that target. Do not resolve these conflicts using insertion order or confidence. The overlay is chosen from the record before the grant and request are applied, so a winning overlay that the grant or request withholds is omitted, and the baseline it replaces is never disclosed in its place.
Fasting and holiday context are additive, time-bounded states. Reduced walking after injury is a temporary safety-related fact, not permission to replace a standing requirement. A month without alcohol can temporarily replace a standing drink preference. These choices do not automatically reveal why, where or with whom.
For ordinary baseline conflicts, the person's declared value takes priority over observed/derived candidates. Multiple incompatible declarations require the person's choice before replacing the current selected baseline. Imports do not silently choose one. Many-cardinality keys retain individually eligible entries. All safety-critical keys are many-cardinality so several allergies, alerts or needs coexist; replacing one cannot remove another.
A4.5 Derivations
At disclosure, recursively validate every dependency's current version, validity, purpose, grant rights and actual fields/level used. Domain permission alone is insufficient: permission for an L1 summary does not authorise deriving from hidden L3 identifiers. Reject cycles, depth above 16, more than 256 dependency references, absent inputs and stale versions. The limit counts every reference traversed from the disclosed entry, along every path and without de-duplication: an input reached by several paths, or named more than once, counts each time it is reached, and so do its own references. Recompute or withhold on any change or expiry. Never disclose dependency identifiers or raw source history through a preference read. In v1, dependency field references are value for the whole stored value or value.<member> for one named own member of a structured value. Nested paths, array indexes, wildcards, metadata and unknown members are unsupported and MUST be withheld. The required level must support the actual referenced field: a category or approved text override does not authorise its raw source value; a first-name rendering authorises value.first, not value.full or the whole name. Dependencies are checked under the same grant purpose and the request's level, declaration and confidence restrictions. The request's output domains and keys need not name an input, but the stored grant must permit it.
A separately confirmed declared preference can be shared independently of raw history. That is an explicit confirmation decision; accepting a stream or trusting a contributor does not perform it.
A4.6 Temporary context
The precise representation is A4's semantic kind, UTC interval and optional baseline-targeting overlay. A temporary overlay requires a finite end and explicit activation. A fasting period or holiday is a bounded additive state; a month without alcohol is a drink-preference overlay. Grant expiry and entry expiry are independent.
The provider captures one trusted instant per transaction. Start is inclusive and end exclusive. Future context is withheld until its start; expired or disabled context stops on the next read without waiting for a cleanup job. The person's timezone is resolved when turning dates into instants. Version 1 deliberately omits recurrence; the person confirms each new interval.
An overlay never rewrites the standing preference. When it ends, the eligible baseline returns. It cannot weaken a safety fact. A single eligible enabled overlay applies without a selection. Conflicting overlays require the person's choice; while several eligible overlays compete without exactly one of them selected, use the baseline (A4.4). Turning a temporary preference into a lasting one is a separate explicit action.
Dependencies, derived values and caches cannot preserve an expired temporary state. Disclosure validity includes the next relevant time boundary; a bodyless conditional response cannot renew it. Permanent history, deletion and a recipient's previously received copy are separate lifecycle questions.
Checks: DISC-01, TEMP-01 to TEMP-03, CONTRIB-01 to CONTRIB-03, INFER-01, WIRE-01, PORT-01.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.