{ "vercy": "1.0-draft", "metaModel": { "id": "enterprise-source-synchronization", "registryId": "vr.profile.enterprise-source-synchronization", "name": "Enterprise Source Synchronization", "version": "0.1.0", "kind": "companion-contract", "logicalKind": "source-synchronization-register" }, "canonicalUrl": "https://ver.cy/models/enterprise-source-synchronization/versions/0.1.0/spec.json", "model": { "purpose": "Connect qualified source records to existing company subjects, preserve immutable intake evidence and explain synchronization progress without inventing identity or deletion.", "scope": "# Enterprise Source Synchronization 0.1.0\n\nThis original companion specifies a locally owned register of source declarations, purpose-qualified record-to-subject mappings, intake receipts and snapshot coverage. It records metadata and protected evidence references. It does not acquire source bytes or apply business facts. A board ABOUT a Project is an aboutness claim, not board IS Project and not permission to create a Project.\n\n## Identity and boundaries\n\nSyncRegister has one registerId (at most 160 characters, reserving room for derived occurrence IDs), one Dimension, one bootstrap administrator and one protected evidence namespace. The immutable local SQLite journal is its master; the derived state, archive and native projection are views. Changing bootstrap identity requires a new register. No tenant, Company, Project, Person, Dataset or source record is created as a business subject here. Target catalogue entries are host-supplied references to separately governed subjects.\n\nSourceInstance declares a product reference, exact tenant/environment and source-instance generation. Its ID and declaration cannot be edited. Another installation of a connector does not necessarily mean another source instance; installation/credential lifecycle is external. The reference rejects duplicate declared product/tenant/environment/generation tuples. It cannot discover undisclosed aliases or prove source continuity.\n\nAcquisitionScope is an immutable, locally identified interpretation of an unpartitioned stream: source ID, resource, scheme/version, source object kind, source-query projection, filter, principal visibility, adapter interpretation and schema evidence. Its fingerprint excludes the local scope ID. Equal fingerprints cannot be registered twice. Mapping revisions and per-round source positions are not acquisition-scope components. Partition/global states and unknown schema properties are refused. The protected evidence references are compared literally; a re-wrapped reference yields a new fingerprint even if an external operator believes its meaning unchanged.\n\nA qualified source lineage is the exact tuple (SourceInstance ID, source-instance generation, resource, scheme, schemeVersion, lexical key, record generation). There is no number conversion, case folding, Unicode normalization or same-as inference. `01` differs from `1`; tenants and resource namespaces qualify `42`. Record generation and synchronization epoch are different: token expiry changes progress context, not automatically record identity. Unknown record generation is non-joinable, never an implicit generation 1.\n\nRecordKey may carry unknown generation and no evidence; it is then accepted only as an unpinned occurrence with continuity-unknown. Known generation requires an evidence declaration based on source incarnation, source non-reuse guarantee or steward attestation. Source attribution must name the declared SourceInstance; steward attestation must name the admitted actor and requires mapping permission. These are host-verified declarations, not cryptographic source authentication.\n\n## Aboutness mapping and history\n\nRecordSubjectMapping has immutable ID, complete known lineage, target subject/kind, purpose, issuer, validity interval, evidence and optional correction predecessor. The creating actor must be the issuer. Mapping admission requires a trusted target catalogue match and an allowed (sourceKind, targetKind, purpose) pair; arbitrary kinds are governed values rather than Identity's four-kind enum. Source kind comes from the trusted scope interpretation. A proposed mapping can activate, dispute or retract; active can dispute/retract; disputed can activate/retract; retraction is terminal. Every activation checks uniqueness across all mapping IDs and revisions for complete lineage plus purpose.\n\nChanging a target, key, generation, purpose, kind or issuer requires a new mapping ID. A replacement that declares corrects must name an earlier claim in the same scope, purpose and known lineage, and cannot activate until that predecessor is retracted. A different-key claim needs independent retirement and new admission without a misleading correction edge. Any current map grantee for the claim scope/purpose may transition it; issuer attribution remains immutable. A zero-active interval is allowed. The first release exposes separate guarded transitions, not an atomic replace convenience API. At no point can two claims for one lineage/purpose be active. Renames of source content do not edit the mapping.\n\nAt first batch admission, each record gets a derived mapping outcome. A pin can use only a mapping declared in that same acquisition scope and purpose. Another scope with the same qualified lineage does not inherit its mapping, even if only the filter changed; its outcome is unmapped. Global lineage/purpose uniqueness still reserves an active claim across scopes. To move governance, a steward with current map grants for both scopes explicitly retracts the old claim and activates a separately proposed new one. Cross-scope corrects is refused; host evidence records the migration instead. Historical pins are unchanged. A pin names mapping ID/state revision, target catalogue revision and current policy revision. The mapping validity window is checked against connector-declared observedAt. The state revision is selected at receipt time, not reconstructed from sourceEventTime. A later retraction or correction does not repin historical occurrences. Within the same immutable scope, a catalogue reclassification or observedAt outside the mapping validity window suspends new pins with active-pin-suspended, while the old active claim still reserves uniqueness until steward action. A changed source-kind interpretation requires a new scope; until a mapping in that receiving scope is activated, its outcome is unmapped, never an inherited suspended pin. Unknowns yield continuity-unknown; known lineages without an active claim yield unmapped. Disputed claims confer no operative pin.\n\nThis is a narrow combination of fixed mapping validity and append-only receipt knowledge. It is not a universal bitemporal mapping engine: future-effective state transitions, assignment closure revisions, retroactive repinning and historical reprocessing are deferred. historical_cut reports the journal known by a host receipt timestamp; within one second sequence remains the ordering key.\n\n## Permission and host trust\n\nBootstrap administration can declare sources/scopes, replace versioned host catalogue/policy, open/close epochs and advance fences. It does not automatically receive intake, mapping or ordinary receipt-read permission. Mapping/round identifiers are register-global, not secret per-scope namespaces. A foreign scope/purpose ID collision and a foreign active-lineage reservation produce uniform DENIED without diagnostic detail. They can still reveal that an identifier or lineage is unavailable compared with a fresh successful proposal. Hosts allocate collision-resistant IDs and coordinate namespace stewardship. Receipt IDs expose register-wide sequence/activity; no concealment guarantee is made. There is no ordinary API for head/fence discovery: a trusted coordinator supplies current preconditions across purposes in a shared epoch. A current exact Grant binds actor, scope, purpose, a subset of intake/map/read/attest-coverage, and a half-open validity interval. No wildcard, group inheritance, delegation chain or real IAM integration ships. Authentication, source/steward verification, policy-issuer competence and current time are trusted host inputs. A grant and a source's semantic priority remain distinct.\n\nUnauthorized/revoked calls return the same not-accepted shape before receipt lookup and append no canonical event. Host denial telemetry is external. Write-only callers get a minimal receipt ID/status for their own successful commit or exact own retry. A different current writer colliding with the same scope/epoch-wide key receives no receipt, and a compact restricted diagnostic may be retained within the separate diagnostic budgets. It can still infer one bit that the key is unavailable by comparing refusal with success for a fresh key. No timing side-channel or zero-knowledge claim is made. Recovery under a replacement principal needs current read permission or an operator lookup; write-only recovery rights do not transfer automatically.\n\nread_receipt checks current read grant and purpose. Full archives, offline history validation, historical_cut and assess_rounds are privileged host functions, not partial disclosure APIs. Native exports must remain subject to current host disclosure; copying them does not enforce a later revocation. Errors for authorized malformed inputs and privileged diagnostics are not public-safe responses. No real addresses, tokens or credentials occur in fixtures. A secret disguised as a permitted identifier is not detected by this schema; the host is responsible for classification and safe input.\n\n## Atomic intake and replay\n\nThe first release supports one local SQLite database with rollback journal and FULL synchronous mode. BEGIN IMMEDIATE serializes writers. Each retained event is one immutable journal entry with sequence, previous digest, actor, host receipt time, accepted command or compact conflict observation, minimal result, full-derived-state outcomeDigest and event digest. The bootstrap, archive and native snapshot carry buildId: SHA-256 over the exact UTF-8 source file bytes, a NUL separator and exact schema file bytes. The chain root binds configuration and buildId. Replay requires that exact installed build and verifies the result and complete state digest after every event; changed code/schema cannot silently reinterpret stored outcomes. The reports record tested Python, SQLite and dependency versions. requirements.txt pins jsonschema only; there is no complete runtime or transitive dependency lock. Other environments need validation; recording a version is not pinning its executable bytes. Build hashes establish integrity, not trusted authorship. Replaying the journal derives configuration, mappings, epochs, receipts and conflicts. The database journal, not a replaceable query index, is the master. A hash chain proves internal byte consistency only; it cannot prove authenticity or that a coherent copy is current.\n\nSyncEpoch belongs to one scope. Only one epoch per scope can be open. It begins with fence 1, no head and progress 0. A trusted administration command advances the fence independently of progress and is journaled. An incoming new batch needs the exact current fence and expected head inside the same write transaction. Tokens are opaque protected references; neither token text nor source wall clock is sorted to find the head. Local progress sequence orders receipts.\n\nBatch identity is (scopeId, epochId, batchKey), independent of writer and mapping revisions. The host/extractor must preserve that key across retry. The reference does not deduplicate arbitrarily repaginated deliveries under new keys. Client content includes ordered input descriptors, purpose, round/page declarations and token evidence. attemptId, expectedHead, fence and computed mapping outcomes are outside content identity. The first implementation has no optional expected-mapping-revision input.\n\nAdmission order is: authenticate/authorize; validate closed input; refuse a closed/wrong epoch; look up the key; return the original own acknowledgement for identical content; retain a conflict for a different principal or changed content; only for a new key evaluate head/fence and first-admission guards. Identical retry after later progress, fence change or mapping correction short-circuits stale preconditions, never readmits or repins the batch and creates no canonical event. Loading the store does recompute historical derived state under its exact build and checks every outcomeDigest. It still requires current intake permission. After epoch close, COMMIT uniformly refuses; separate authorized READ may recover history.\n\nThe single local transaction persists original content and the digest of its complete resulting state. Replay reconstructs and verifies derived occurrences, durable quarantine descriptors, received/accepted/quarantined counts, receipt and new head. A receipt is the destination acknowledgement for this local metadata register. It is not confirmation by an independent external business destination. Conservation is received = accepted + quarantined. There is no accept-loss option. Zero records requires empty=true. A rejection descriptor names a protected evidence reference, reason and retry obligation. The reference does not parse or quarantine arbitrary raw source bytes: an upstream adapter classifies each descriptor, while the whole input envelope itself must validate. Quarantine obligations remain open in 0.1.0; automated resolution, erasure and retention execution are deferred. Reingestion is a new batch and does not erase old quarantine.\n\nRecordOccurrence identity is receipt ID plus input ordinal. Repeated identical records within one page retain distinct occurrences and order. Content-reference spelling is part of retry identity. A reissued locator changes the body and conflicts, even if it points to the same external bytes. Digests bind submitted descriptors and do not prove external payload/token acquisition, retention, authenticity, encryption or privacy. Their external evidence store must be managed by the host; no fetch, fsync or token-access check is performed against it.\n\nOnly the committing attemptId and retained conflict attemptIds enter this journal. A rejected authorized commit retains only its qualified key, attempt, preconditions, supplied digest and conflict reason, never its full rejected payload or record descriptors. Replaying this internal observation independently verifies the conflict against prior state; clients cannot submit internal observations. At most 32 conflicts total and 4 per actor/scope/epoch are retained. Diagnostic budget exhaustion, the 128-event limit or insufficient archive space yields the same refusal with no event or head change. Full denial/attempt telemetry and capacity monitoring belong outside this finite reference. A digest collision with unequal canonical content is refused without a diagnostic. Exact-retry attempts, failed-before-commit attempts, denied calls and invalid envelopes remain external telemetry. There is no crash-durable running ExtractionAttempt object. Fault tests exercise a process exiting before and after SQLite COMMIT, not storage hardware/power-loss certification. Storage that lies about flush or locking remains outside the guarantee. Multi-host fencing, distributed exactly-once, external effects and cross-register transactions are not implemented.\n\n## Occurrence time, corrections and competing facts\n\nobservedAt is connector-declared acquisition time. sourceEventTime is nullable and never invented from observedAt or host time. recordedAt/committedAt come from the trusted host; journal sequence disambiguates equal host timestamps. The host receipt clock cannot move backwards along the journal, but no ordering across source clocks is asserted.\n\nAn occurrence correction references an earlier retained occurrence of the same known lineage, scope and purpose. In addition to intake, it needs current map and read grants and declared source-or-steward attribution; foreign-scope/purpose and nonexistent targets receive the same refusal without a canonical event. Source-or-steward attribution is then checked; source attribution names SourceInstance, steward attribution names the admitted actor. It creates a new occurrence and retains the old one. The reference does not adjudicate which competing source value is true. It retains both evidence references and routes fact selection to separately governed authority; no EFA or EAP adapter executes automatically. Source-deleted, removed-from-scope and inaccessible are source-availability observations, never business-subject retirement.\n\n## Snapshot coverage and comparison\n\nSnapshotRound declares one scope/epoch/purpose, consistency kind/evidence, whether visibility is covered by the source guarantee, and optional earlier round plus not-earlier evidence. For a round declaring source-snapshot consistency or visibilityCovered=true, opening it, admitting a new terminal page, and sealing without errors each require current attest-coverage as well as intake. Revocation is rechecked at each of those admissions; an exact committed batch retry still returns only its original acknowledgement under the existing intake retry rule. Nonterminal pages may be supplied by intake-only actors. An intake actor may seal with explicit nonempty error evidence, which always makes complete=false and cannot support absence. This records host-authorized attestation; it does not verify external completeness. Intake-only writers may declare best-effort with visibilityCovered=false. The earlier round must already be sealed in the same scope. Pages commit in contiguous zero-based order; no page can follow terminal=true. A nonterminal page can advance local progress but cannot complete a round. A round must be sealed, including error evidence for a partial result, before its epoch closes. It cannot accept pages after sealing. If its writer loses permission, an administrator must explicitly grant an operator (including itself) intake for that scope/purpose to seal an orphaned round with error evidence. Admin has no implicit intake. Hosts must reserve capacity for closure; no special over-budget recovery or rollover exists.\n\nThe reference's complete flag is deliberately a strong key-accounting condition: a terminal page exists, no error or quarantine remains in the round, and all retained items are snapshot-read with known generations. It does not certify actual source completeness. Best-effort may be fully accounted yet cannot support absence comparison. A host must establish actual consistency and visibility before declaring them.\n\nassess_rounds validates the complete restricted archive first. It requires two complete rounds, increasing local seal sequence, identical scope/purpose, source-snapshot consistency in both, visibilityCovered in both and the later round's explicit earlier-round/not-earlier witness. Opaque LSN/token values are not compared. Different epochs alone do not break comparison. Changed source-instance generation, filter, principal visibility or interpretation changes the scope and breaks it. Unknown order, missing pages or inadequate key coverage returns insufficient-context.\n\nFor a known lineage present in the earlier round and not the later, an explicit intervening deletion/removal/inaccessibility observation is reported separately. Otherwise the result is only not-observed-in-comparable-rounds with steward-review-only action and an empty effects list. Same principal does not prove unchanged per-object visibility. No absence result deletes data, retracts a mapping, chooses a fact or retires a subject. Cross-register/foreign-archive round comparison is not implemented.\n\n## Export, versions and operational limits\n\nArchives preserve bootstrap, buildId, complete journal, exact derived state, root and version. validate_archive recomputes history and rejects edited outcomes, missing evidence, changed state, unsupported versions or a different executable/schema build. Derived state is compared by canonical bytes, including exact boolean versus integer types. Earlier unreleased 0.1.0 candidate builds are not interchangeable; they remain frozen historical evidence and need their exact original code/schema to inspect. No automatic migration is provided. inspect_import returns a historical-only report or an explicit LossReport. It does not create a writable database. resume_archive always refuses. Original epoch states remain unchanged as historical evidence; the archive wrapper is non-resumable. Upgrade/downgrade transformations, origin-host handover and writable restoration are deferred, not silently approximated.\n\nA normal process restart can reopen the same locally owned database. The host must establish that it is the current owned store. A crash before bootstrap commits may leave an uninitialized file. An empty store is explicitly refused and preserved; do not overwrite it automatically. An operator inspects the file and establishes a new owned path/baseline if initialization never completed. Other corrupt/partial store errors remain host recovery events. The reference cannot detect a coherent old backup or two cloned databases and has no live ownership token service. Another host starts a new local register/epoch and fresh acquisition baseline; it does not continue from an imported token. Fresh-source/baseline truth remains external because this reference has no network connector.\n\nBudgets: 128 retained journal entries; 256 input records/descriptors per batch; 256 catalogue targets/pairs/grants; 32 round-error references; one complete archive at most 512 KiB of the reference's canonical JSON encoding. A new retained event is refused before persistence if its archive would exceed the budget; no-event exact retries and uniform refusals remain available at the event limit. Conflict diagnostics also have the separate bounds described above. Generated journal entries are schema-checked before persistence. These are demonstration limits, not enterprise throughput targets. The journal is replayed on each operation and hashes the growing state at every event; this can be quadratic work per call under a database lock. The earlier candidate 2,000-event/8-MiB limits are withdrawn. benchmark.py records a synthetic run near both new limits, with large state present early and two process writers. Its timings are observations, not an SLA or certification under every host load. SQLite busy/lock errors can still occur and are host operational errors, not authorization refusals. Large-scale indexing/partitioning needs a separately reviewed implementation.\n\nCanonical encoding uses Python sorted-key, compact, UTF-8 JSON with ordered arrays; floats, duplicate JSON keys, non-string keys, C0/DEL/C1 control characters and unpaired surrogates are refused. JSON text bytes must be UTF-8 without BOM. Raw transport has a separate 8 MiB UTF-8 byte limit, including whitespace and escape spelling; the parsed canonical value remains limited to 512 KiB. Whitespace and key order within that transport budget are accepted and canonicalized. Excessive JSON nesting returns a structured import refusal; no unbounded parser support is promised. Stored journal/bootstrap blobs must already use exact canonical encoding. All lexical schema patterns require absolute end of string, so a trailing newline cannot pass. Other Unicode characters, including format/zero-width characters, remain distinct lexical values; viewers must escape ambiguous display safely. It is explicitly not RFC 8785/JCS. IDs are restricted URNs, lexical source keys remain exact bounded strings. Supplied SHA-256 values are declarations; no payload is fetched to confirm them. Schema version, object revision, journal sequence, epoch and source/record generation are independent values.\n\n## Native binding and release posture\n\nThe native V3 binding is one SyncRegister object and a restricted sync.register.snapshot fact pointing to this exact companion/version and carrying its closed journal snapshot. The snapshot omits redundant derived state; installed replay reconstructs the exact complete archive. sync.schema.json closes this native value at the root, with command and journal definitions in $defs. The native fact profile rejects extra envelope fields and requires exact authority types. One aggregate projection has an explicit owner, boundary and calculation rule. Its fact ID is determined by journal root; exporting the same cut at a later capture time can change envelope bytes but cannot create a new fact identity. Keep the first stored fact; the native writer rejects duplicate IDs. Only strict journal extensions supersede a trusted predecessor. That predecessor must already have been validated by the host, including its provenance. Generic business fact resolution must not treat this register snapshot as a Project field. Native outer validation and installed companion replay must both run; outer validity alone does not establish nested semantics, authenticity or current state.\n\nThis file currently describes an implementation candidate. Executed test reports and native acceptance state what was run. Separate frozen Claude/Grok audits are tracked in review.json and review.md; this candidate text alone makes no audit-acceptance claim. Published lifecycle, research assurance, implementation evidence and broader-contour completion remain separate. A source synchronization package is not a Company model or a production connector deployment.\n\n## Deterministic availability evidence\n\nAbsence assessment uses only availability occurrences from the compared scope and purpose. When multiple observations concern one lineage between the seals, the latest is selected by (receipt sequence, input ordinal), never dictionary or lexical key order. Canonical JSON export/import therefore preserves this result. Source-event clocks are not used to reorder host-admitted observations.\n\nShared-round coordination: an intake grantee may append nonterminal pages to an attested round or close it with nonempty error evidence, always incomplete. Page slots are shared, so one writer can displace another writer's planned page. The current attester must inspect and verify the entire admitted page set before terminal admission and an error-free seal, including pages supplied by other writers. The host coordinates contributors, source completeness and recovery; the reference neither reserves page ownership nor proves that the attester actually performed this review. Current attestation gates prevent intake-only successful completion, not interference by an authorized contributor.\n" }, "structure": { "bundles": [ { "id": "SS-B1", "name": "Sources", "description": "Sources questions, evidence and guarded decisions.", "layers": [ { "id": "SS-B1-L1", "name": "Source identity", "description": "Source identity of a source synchronization register.", "findings": [ { "id": "SS-F01", "name": "Source instance", "description": "Immutable SourceInstance declaration and continuity evidence", "questions": [ { "id": "SS-Q01", "text": "Which actual tenant and environment emits these records?", "kind": "host-guidance", "answer_data": [ "Immutable SourceInstance declaration and continuity evidence", "Register a new instance generation only after host verification." ] }, { "id": "SS-Q02", "text": "What evidence distinguishes a restored or recreated instance?", "kind": "host-guidance", "answer_data": [ "Immutable SourceInstance declaration and continuity evidence", "Register a new instance generation only after host verification." ] } ], "artifacts": [ { "id": "SS-A01", "name": "Immutable SourceInstance declaration and continuity evidence", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT01", "description": "Register a new instance generation only after host verification. Requires applicable host authority." } ] }, { "id": "SS-F02", "name": "Qualified keys", "description": "Source, resource, scheme/version, exact key and record generation", "questions": [ { "id": "SS-Q03", "text": "What qualifies this local record key?", "kind": "host-guidance", "answer_data": [ "Source, resource, scheme/version, exact key and record generation", "Preserve lexical bytes and namespace; never infer identity from a display name." ] }, { "id": "SS-Q04", "text": "Are lexical differences or recycled keys being hidden?", "kind": "host-guidance", "answer_data": [ "Source, resource, scheme/version, exact key and record generation", "Preserve lexical bytes and namespace; never infer identity from a display name." ] } ], "artifacts": [ { "id": "SS-A02", "name": "Source, resource, scheme/version, exact key and record generation", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT02", "description": "Preserve lexical bytes and namespace; never infer identity from a display name. Requires applicable host authority." } ] }, { "id": "SS-F03", "name": "Continuity", "description": "Generation evidence with source or authorized steward attribution", "questions": [ { "id": "SS-Q05", "text": "Is the record generation known?", "kind": "host-guidance", "answer_data": [ "Generation evidence with source or authorized steward attribution", "Keep unknown continuity unpinned; do not invent a generation." ] }, { "id": "SS-Q06", "text": "Who can attest non-reuse or an incarnation?", "kind": "host-guidance", "answer_data": [ "Generation evidence with source or authorized steward attribution", "Keep unknown continuity unpinned; do not invent a generation." ] } ], "artifacts": [ { "id": "SS-A03", "name": "Generation evidence with source or authorized steward attribution", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT03", "description": "Keep unknown continuity unpinned; do not invent a generation. Requires applicable host authority." } ] } ] }, { "id": "SS-B1-L2", "name": "Acquisition interpretation", "description": "Acquisition interpretation of a source synchronization register.", "findings": [ { "id": "SS-F04", "name": "Scope boundary", "description": "Immutable scope and literal evidence-reference fingerprint", "questions": [ { "id": "SS-Q07", "text": "Which filter, projection and visibility does this acquisition cover?", "kind": "host-guidance", "answer_data": [ "Immutable scope and literal evidence-reference fingerprint", "Create a new scope for changed interpretation; do not compare incompatible coverage." ] }, { "id": "SS-Q08", "text": "Did interpretation or schema change?", "kind": "host-guidance", "answer_data": [ "Immutable scope and literal evidence-reference fingerprint", "Create a new scope for changed interpretation; do not compare incompatible coverage." ] } ], "artifacts": [ { "id": "SS-A04", "name": "Immutable scope and literal evidence-reference fingerprint", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT04", "description": "Create a new scope for changed interpretation; do not compare incompatible coverage. Requires applicable host authority." } ] }, { "id": "SS-F05", "name": "Opaque progress", "description": "Protected token reference, local epoch, fence and head", "questions": [ { "id": "SS-Q09", "text": "What exact source position was retained?", "kind": "host-guidance", "answer_data": [ "Protected token reference, local epoch, fence and head", "Treat tokens as opaque; a new epoch does not itself change business identity." ] }, { "id": "SS-Q10", "text": "Is a token reset being confused with record rebirth?", "kind": "host-guidance", "answer_data": [ "Protected token reference, local epoch, fence and head", "Treat tokens as opaque; a new epoch does not itself change business identity." ] } ], "artifacts": [ { "id": "SS-A05", "name": "Protected token reference, local epoch, fence and head", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT05", "description": "Treat tokens as opaque; a new epoch does not itself change business identity. Requires applicable host authority." } ] } ] } ] }, { "id": "SS-B2", "name": "Mappings", "description": "Mappings questions, evidence and guarded decisions.", "layers": [ { "id": "SS-B2-L1", "name": "Aboutness governance", "description": "Aboutness governance of a source synchronization register.", "findings": [ { "id": "SS-F06", "name": "Subject meaning", "description": "Governed target catalogue and source-kind/target-kind/purpose pair", "questions": [ { "id": "SS-Q11", "text": "Which existing subject is this record about?", "kind": "host-guidance", "answer_data": [ "Governed target catalogue and source-kind/target-kind/purpose pair", "Propose aboutness only; do not create or merge business subjects." ] }, { "id": "SS-Q12", "text": "Is a source board being mistaken for a business Project?", "kind": "host-guidance", "answer_data": [ "Governed target catalogue and source-kind/target-kind/purpose pair", "Propose aboutness only; do not create or merge business subjects." ] } ], "artifacts": [ { "id": "SS-A06", "name": "Governed target catalogue and source-kind/target-kind/purpose pair", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT06", "description": "Propose aboutness only; do not create or merge business subjects. Requires applicable host authority." } ] }, { "id": "SS-F07", "name": "Lifecycle", "description": "Proposed, active, disputed or retracted revisions with activation guard", "questions": [ { "id": "SS-Q13", "text": "Which mapping revision is active?", "kind": "host-guidance", "answer_data": [ "Proposed, active, disputed or retracted revisions with activation guard", "Check complete-lineage/purpose uniqueness on every activation." ] }, { "id": "SS-Q14", "text": "Can a disputed claim reactivate beside another active claim?", "kind": "host-guidance", "answer_data": [ "Proposed, active, disputed or retracted revisions with activation guard", "Check complete-lineage/purpose uniqueness on every activation." ] } ], "artifacts": [ { "id": "SS-A07", "name": "Proposed, active, disputed or retracted revisions with activation guard", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT07", "description": "Check complete-lineage/purpose uniqueness on every activation. Requires applicable host authority." } ] }, { "id": "SS-F08", "name": "Replacement", "description": "New mapping identity, correction predecessor and retained history", "questions": [ { "id": "SS-Q15", "text": "Which earlier mapping is being corrected?", "kind": "host-guidance", "answer_data": [ "New mapping identity, correction predecessor and retained history", "Retract the old claim before activation; a temporary zero-active interval is allowed." ] }, { "id": "SS-Q16", "text": "Has the earlier claim been retracted first?", "kind": "host-guidance", "answer_data": [ "New mapping identity, correction predecessor and retained history", "Retract the old claim before activation; a temporary zero-active interval is allowed." ] } ], "artifacts": [ { "id": "SS-A08", "name": "New mapping identity, correction predecessor and retained history", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT08", "description": "Retract the old claim before activation; a temporary zero-active interval is allowed. Requires applicable host authority." } ] } ] }, { "id": "SS-B2-L2", "name": "Pinned interpretation", "description": "Pinned interpretation of a source synchronization register.", "findings": [ { "id": "SS-F09", "name": "Historical outcome", "description": "Occurrence mapping/state, catalogue and policy revision pins", "questions": [ { "id": "SS-Q17", "text": "Which mapping applied at first admission?", "kind": "host-guidance", "answer_data": [ "Occurrence mapping/state, catalogue and policy revision pins", "Keep the original outcome immutable; inspect later revisions separately." ] }, { "id": "SS-Q18", "text": "Will a later correction silently repin old data?", "kind": "host-guidance", "answer_data": [ "Occurrence mapping/state, catalogue and policy revision pins", "Keep the original outcome immutable; inspect later revisions separately." ] } ], "artifacts": [ { "id": "SS-A09", "name": "Occurrence mapping/state, catalogue and policy revision pins", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT09", "description": "Keep the original outcome immutable; inspect later revisions separately. Requires applicable host authority." } ] }, { "id": "SS-F10", "name": "Suspension", "description": "Current catalogue/validity check within the receiving scope and active-pin-suspended outcome", "questions": [ { "id": "SS-Q19", "text": "Does the current target kind still satisfy the mapping?", "kind": "host-guidance", "answer_data": [ "Current catalogue/validity check within the receiving scope and active-pin-suspended outcome", "Withhold new pins and preserve the active uniqueness reservation until steward action." ] }, { "id": "SS-Q20", "text": "Does a suspended claim still reserve its lineage?", "kind": "host-guidance", "answer_data": [ "Current catalogue/validity check within the receiving scope and active-pin-suspended outcome", "Withhold new pins and preserve the active uniqueness reservation until steward action." ] } ], "artifacts": [ { "id": "SS-A10", "name": "Current catalogue/validity check within the receiving scope and active-pin-suspended outcome", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT10", "description": "Withhold new pins and preserve the active uniqueness reservation until steward action. Requires applicable host authority." } ] } ] } ] }, { "id": "SS-B3", "name": "Intake", "description": "Intake questions, evidence and guarded decisions.", "layers": [ { "id": "SS-B3-L1", "name": "Atomic delivery", "description": "Atomic delivery of a source synchronization register.", "findings": [ { "id": "SS-F11", "name": "Batch identity", "description": "Scope/epoch-wide key and exact ordered content digest", "questions": [ { "id": "SS-Q21", "text": "What identity survives a retry and a writer replacement?", "kind": "host-guidance", "answer_data": [ "Scope/epoch-wide key and exact ordered content digest", "Reuse exact content/key after a lost response; never silently accept changed content." ] }, { "id": "SS-Q22", "text": "Has content changed under the same key?", "kind": "host-guidance", "answer_data": [ "Scope/epoch-wide key and exact ordered content digest", "Reuse exact content/key after a lost response; never silently accept changed content." ] } ], "artifacts": [ { "id": "SS-A11", "name": "Scope/epoch-wide key and exact ordered content digest", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT11", "description": "Reuse exact content/key after a lost response; never silently accept changed content. Requires applicable host authority." } ] }, { "id": "SS-F12", "name": "Commit boundary", "description": "One local SQLite transaction and retained acknowledgement", "questions": [ { "id": "SS-Q23", "text": "Were metadata, receipt and progress committed together?", "kind": "host-guidance", "answer_data": [ "One local SQLite transaction and retained acknowledgement", "Use the owned local store; external payload durability remains a host responsibility." ] }, { "id": "SS-Q24", "text": "Could a crash expose a head without its records?", "kind": "host-guidance", "answer_data": [ "One local SQLite transaction and retained acknowledgement", "Use the owned local store; external payload durability remains a host responsibility." ] } ], "artifacts": [ { "id": "SS-A12", "name": "One local SQLite transaction and retained acknowledgement", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT12", "description": "Use the owned local store; external payload durability remains a host responsibility. Requires applicable host authority." } ] }, { "id": "SS-F13", "name": "Concurrency", "description": "Serialized transaction and restricted conflict diagnostic", "questions": [ { "id": "SS-Q25", "text": "Which expected head and fence admitted this new batch?", "kind": "host-guidance", "answer_data": [ "Serialized transaction and restricted conflict diagnostic", "Refuse stale new admissions; an authorized exact own retry returns its old acknowledgement." ] }, { "id": "SS-Q26", "text": "Does a stale writer advance progress?", "kind": "host-guidance", "answer_data": [ "Serialized transaction and restricted conflict diagnostic", "Refuse stale new admissions; an authorized exact own retry returns its old acknowledgement." ] } ], "artifacts": [ { "id": "SS-A13", "name": "Serialized transaction and restricted conflict diagnostic", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT13", "description": "Refuse stale new admissions; an authorized exact own retry returns its old acknowledgement. Requires applicable host authority." } ] } ] }, { "id": "SS-B3-L2", "name": "Partial failure", "description": "Partial failure of a source synchronization register.", "findings": [ { "id": "SS-F14", "name": "Quarantine", "description": "Durable restricted quarantine evidence and open retry obligation", "questions": [ { "id": "SS-Q27", "text": "Which input descriptors were rejected?", "kind": "host-guidance", "answer_data": [ "Durable restricted quarantine evidence and open retry obligation", "Retain each rejected descriptor; resolve externally and reingest with a new batch." ] }, { "id": "SS-Q28", "text": "Do received counts equal retained accepted plus quarantined counts?", "kind": "host-guidance", "answer_data": [ "Durable restricted quarantine evidence and open retry obligation", "Retain each rejected descriptor; resolve externally and reingest with a new batch." ] } ], "artifacts": [ { "id": "SS-A14", "name": "Durable restricted quarantine evidence and open retry obligation", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT14", "description": "Retain each rejected descriptor; resolve externally and reingest with a new batch. Requires applicable host authority." } ] }, { "id": "SS-F15", "name": "Empty versus missing", "description": "Explicit empty flag, contiguous page indices and terminal marker", "questions": [ { "id": "SS-Q29", "text": "Was an empty page explicitly delivered?", "kind": "host-guidance", "answer_data": [ "Explicit empty flag, contiguous page indices and terminal marker", "Keep missing coverage insufficient; do not infer business deletion." ] }, { "id": "SS-Q30", "text": "Are missing pages or transport failures being treated as an empty source?", "kind": "host-guidance", "answer_data": [ "Explicit empty flag, contiguous page indices and terminal marker", "Keep missing coverage insufficient; do not infer business deletion." ] } ], "artifacts": [ { "id": "SS-A15", "name": "Explicit empty flag, contiguous page indices and terminal marker", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT15", "description": "Keep missing coverage insufficient; do not infer business deletion. Requires applicable host authority." } ] } ] } ] }, { "id": "SS-B4", "name": "Evidence", "description": "Evidence questions, evidence and guarded decisions.", "layers": [ { "id": "SS-B4-L1", "name": "Time and availability", "description": "Time and availability of a source synchronization register.", "findings": [ { "id": "SS-F16", "name": "Three clocks", "description": "Nullable sourceEventTime, declared observedAt, trusted recordedAt and sequence", "questions": [ { "id": "SS-Q31", "text": "When did the source event, acquisition and host receipt occur?", "kind": "host-guidance", "answer_data": [ "Nullable sourceEventTime, declared observedAt, trusted recordedAt and sequence", "Preserve unknown source time and compare only the appropriate clock." ] }, { "id": "SS-Q32", "text": "Was an unknown source time invented?", "kind": "host-guidance", "answer_data": [ "Nullable sourceEventTime, declared observedAt, trusted recordedAt and sequence", "Preserve unknown source time and compare only the appropriate clock." ] } ], "artifacts": [ { "id": "SS-A16", "name": "Nullable sourceEventTime, declared observedAt, trusted recordedAt and sequence", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT16", "description": "Preserve unknown source time and compare only the appropriate clock. Requires applicable host authority." } ] }, { "id": "SS-F17", "name": "Occurrence correction", "description": "Earlier occurrence reference, known lineage and steward admission", "questions": [ { "id": "SS-Q33", "text": "Which retained occurrence is corrected?", "kind": "host-guidance", "answer_data": [ "Earlier occurrence reference, known lineage and steward admission", "Append correction evidence; keep the old occurrence unchanged." ] }, { "id": "SS-Q34", "text": "Is correction lineage and attribution valid?", "kind": "host-guidance", "answer_data": [ "Earlier occurrence reference, known lineage and steward admission", "Append correction evidence; keep the old occurrence unchanged." ] } ], "artifacts": [ { "id": "SS-A17", "name": "Earlier occurrence reference, known lineage and steward admission", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT17", "description": "Append correction evidence; keep the old occurrence unchanged. Requires applicable host authority." } ] }, { "id": "SS-F18", "name": "Source availability", "description": "Explicit source-availability operation", "questions": [ { "id": "SS-Q35", "text": "Was a source record deleted, removed from scope or inaccessible?", "kind": "host-guidance", "answer_data": [ "Explicit source-availability operation", "Retain availability evidence without changing the subject lifecycle." ] }, { "id": "SS-Q36", "text": "Does that authorize retirement of a business subject?", "kind": "host-guidance", "answer_data": [ "Explicit source-availability operation", "Retain availability evidence without changing the subject lifecycle." ] } ], "artifacts": [ { "id": "SS-A18", "name": "Explicit source-availability operation", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT18", "description": "Retain availability evidence without changing the subject lifecycle. Requires applicable host authority." } ] } ] }, { "id": "SS-B4-L2", "name": "Coverage assessment", "description": "Coverage assessment of a source synchronization register.", "findings": [ { "id": "SS-F19", "name": "Round completion", "description": "Sealed terminal round and separate consistency/visibility declarations", "questions": [ { "id": "SS-Q37", "text": "Were all pages accounted for without quarantine or unknown keys?", "kind": "host-guidance", "answer_data": [ "Sealed terminal round and separate consistency/visibility declarations", "Distinguish strong local key accounting from a verified source guarantee." ] }, { "id": "SS-Q38", "text": "Does this prove that the external source is actually complete?", "kind": "host-guidance", "answer_data": [ "Sealed terminal round and separate consistency/visibility declarations", "Distinguish strong local key accounting from a verified source guarantee." ] } ], "artifacts": [ { "id": "SS-A19", "name": "Sealed terminal round and separate consistency/visibility declarations", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT19", "description": "Distinguish strong local key accounting from a verified source guarantee. Requires applicable host authority." } ] }, { "id": "SS-F20", "name": "Comparable absence", "description": "Explicit not-earlier witness and complete source-snapshot rounds", "questions": [ { "id": "SS-Q39", "text": "Are two rounds of the same scope genuinely ordered and comparable?", "kind": "host-guidance", "answer_data": [ "Explicit not-earlier witness and complete source-snapshot rounds", "Emit only a steward-review proposal and no effects." ] }, { "id": "SS-Q40", "text": "Could visibility or a new interpretation explain the missing key?", "kind": "host-guidance", "answer_data": [ "Explicit not-earlier witness and complete source-snapshot rounds", "Emit only a steward-review proposal and no effects." ] } ], "artifacts": [ { "id": "SS-A20", "name": "Explicit not-earlier witness and complete source-snapshot rounds", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT20", "description": "Emit only a steward-review proposal and no effects. Requires applicable host authority." } ] }, { "id": "SS-F21", "name": "Competing evidence", "description": "Both retained evidence references and separately governed selection policy", "questions": [ { "id": "SS-Q41", "text": "Do different sources disagree about a subject?", "kind": "host-guidance", "answer_data": [ "Both retained evidence references and separately governed selection policy", "Do not let arrival order or connector ownership choose business truth." ] }, { "id": "SS-Q42", "text": "Which separate authority contract can adjudicate those facts?", "kind": "host-guidance", "answer_data": [ "Both retained evidence references and separately governed selection policy", "Do not let arrival order or connector ownership choose business truth." ] } ], "artifacts": [ { "id": "SS-A21", "name": "Both retained evidence references and separately governed selection policy", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT21", "description": "Do not let arrival order or connector ownership choose business truth. Requires applicable host authority." } ] } ] } ] }, { "id": "SS-B5", "name": "Operation", "description": "Operation questions, evidence and guarded decisions.", "layers": [ { "id": "SS-B5-L1", "name": "Rights and custody", "description": "Rights and custody of a source synchronization register.", "findings": [ { "id": "SS-F22", "name": "Current permission", "description": "Current exact host grant and authenticated actor", "questions": [ { "id": "SS-Q43", "text": "Can this actor intake, map, read or attest coverage for this purpose now?", "kind": "host-guidance", "answer_data": [ "Current exact host grant and authenticated actor", "Check each right independently; never derive permission from semantic source priority." ] }, { "id": "SS-Q44", "text": "Does bootstrap administration imply ordinary writer permission?", "kind": "host-guidance", "answer_data": [ "Current exact host grant and authenticated actor", "Check each right independently; never derive permission from semantic source priority." ] } ], "artifacts": [ { "id": "SS-A22", "name": "Current exact host grant and authenticated actor", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT22", "description": "Check each right independently; never derive permission from semantic source priority. Requires applicable host authority." } ] }, { "id": "SS-F23", "name": "Restricted disclosure", "description": "Current read decision, protected projections and documented key-unavailability bit", "questions": [ { "id": "SS-Q45", "text": "Can this result or diagnostic be disclosed now?", "kind": "host-guidance", "answer_data": [ "Current read decision, protected projections and documented key-unavailability bit", "Keep full archives privileged; acknowledge the residual availability side channel." ] }, { "id": "SS-Q46", "text": "What can a competing authorized writer infer from refusal?", "kind": "host-guidance", "answer_data": [ "Current read decision, protected projections and documented key-unavailability bit", "Keep full archives privileged; acknowledge the residual availability side channel." ] } ], "artifacts": [ { "id": "SS-A23", "name": "Current read decision, protected projections and documented key-unavailability bit", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT23", "description": "Keep full archives privileged; acknowledge the residual availability side channel. Requires applicable host authority." } ] }, { "id": "SS-F24", "name": "Evidence custody", "description": "Host-managed protected evidence references", "questions": [ { "id": "SS-Q47", "text": "Where are payloads, tokens and verification evidence stored?", "kind": "host-guidance", "answer_data": [ "Host-managed protected evidence references", "Verify custody externally; the reference neither fetches nor authenticates payload bytes." ] }, { "id": "SS-Q48", "text": "Does a submitted digest prove they exist or are safe?", "kind": "host-guidance", "answer_data": [ "Host-managed protected evidence references", "Verify custody externally; the reference neither fetches nor authenticates payload bytes." ] } ], "artifacts": [ { "id": "SS-A24", "name": "Host-managed protected evidence references", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT24", "description": "Verify custody externally; the reference neither fetches nor authenticates payload bytes. Requires applicable host authority." } ] } ] }, { "id": "SS-B5-L2", "name": "Adoption and recovery", "description": "Adoption and recovery of a source synchronization register.", "findings": [ { "id": "SS-F25", "name": "Native binding", "description": "One register object, snapshot facts and explicit extension validation", "questions": [ { "id": "SS-Q49", "text": "Does the stored snapshot preserve the full semantic journal?", "kind": "host-guidance", "answer_data": [ "One register object, snapshot facts and explicit extension validation", "Validate both envelopes and nested history; the snapshot is a restricted projection." ] }, { "id": "SS-Q50", "text": "Did installed companion validation run after outer checks?", "kind": "host-guidance", "answer_data": [ "One register object, snapshot facts and explicit extension validation", "Validate both envelopes and nested history; the snapshot is a restricted projection." ] } ], "artifacts": [ { "id": "SS-A25", "name": "One register object, snapshot facts and explicit extension validation", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT25", "description": "Validate both envelopes and nested history; the snapshot is a restricted projection. Requires applicable host authority." } ] }, { "id": "SS-F26", "name": "Restore continuity", "description": "External ownership/current-root evidence and historical-only import report", "questions": [ { "id": "SS-Q51", "text": "Is this the current owned database or a coherent old copy?", "kind": "host-guidance", "answer_data": [ "External ownership/current-root evidence and historical-only import report", "Refuse writable archive import; establish a fresh baseline on another host." ] }, { "id": "SS-Q52", "text": "Can an archive legitimately resume an external token?", "kind": "host-guidance", "answer_data": [ "External ownership/current-root evidence and historical-only import report", "Refuse writable archive import; establish a fresh baseline on another host." ] } ], "artifacts": [ { "id": "SS-A26", "name": "External ownership/current-root evidence and historical-only import report", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT26", "description": "Refuse writable archive import; establish a fresh baseline on another host. Requires applicable host authority." } ] }, { "id": "SS-F27", "name": "Minimum profile", "description": "Synthetic startup, international and AI cases with explicit limits", "questions": [ { "id": "SS-Q53", "text": "Which small source/mapping boundary is useful today?", "kind": "host-guidance", "answer_data": [ "Synthetic startup, international and AI cases with explicit limits", "Start with the smallest reviewed scope; scale storage and connectors under a separate contract." ] }, { "id": "SS-Q54", "text": "Which enterprise capabilities are still deferred?", "kind": "host-guidance", "answer_data": [ "Synthetic startup, international and AI cases with explicit limits", "Start with the smallest reviewed scope; scale storage and connectors under a separate contract." ] } ], "artifacts": [ { "id": "SS-A27", "name": "Synthetic startup, international and AI cases with explicit limits", "description": "Retained or host-verified evidence; unknown context is explicit." } ], "actions": [ { "id": "SS-ACT27", "description": "Start with the smallest reviewed scope; scale storage and connectors under a separate contract. Requires applicable host authority." } ] } ] } ] } ] }, "composition": { "runtimeImports": [], "semanticReferences": [ { "id": "WM-XCT-001", "version": "0.3.1-enterprise.1", "url": "https://ver.cy/models/wm-xct-001-ownership-stewardship/spec.yaml", "digest": "sha256:fa942556a3f460729db2e94b24d1efd4d33ee2e5fb0b1deed3ce040756acf474", "relation": "Governance comparison; no inherited mandate schema" }, { "id": "WM-XCT-012", "version": "0.3.0-research.1", "url": "https://ver.cy/models/wm-xct-012-provenance/spec.yaml", "digest": "sha256:aa6155354c55a87ab837ec9bd47f796ca582309fe383f1afffb802dafff7ecb5", "relation": "Attribution/history comparison; no fetching or checkpoint engine" } ], "delivery": "Original companion identity; no parent subtype. One aggregate native object and restricted snapshot path. Pinned WM-XCT-040 composition exercised separately." }, "statistics": { "bundles": 5, "layers": 10, "findings": 27, "questions": 54, "artifacts": 27 }, "wholeObjectFacets": { "SyncRegister": { "identity-class": { "status": "required", "reason": "Immutable register/Dimension/bootstrap identity." }, "direct-properties": { "status": "required", "reason": "Sources, scopes, complete journal and derived state; protected namespace." }, "recognition-observation": { "status": "required", "reason": "Historical replay establishes internal consistency, not current authenticity." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Admin operations and explicitly granted intake/map/read/attest-coverage; archive cannot resume." }, "context-evidence": { "status": "required", "reason": "One owned local SQLite master; native snapshots are restricted evidence." } }, "SourceInstance": { "identity-class": { "status": "required", "reason": "Immutable product/tenant/environment/generation declaration and local ID." }, "direct-properties": { "status": "required", "reason": "Product reference and continuity evidence; no connector credential fields." }, "recognition-observation": { "status": "required", "reason": "Host verifies source continuity; matching labels alone are insufficient." }, "capabilities-behaviour-actions": { "status": "required", "reason": "New generation needs a new declaration; close old epochs explicitly when appropriate." }, "context-evidence": { "status": "required", "reason": "External source operator owns source truth; host owns its declaration." } }, "AcquisitionScope": { "identity-class": { "status": "required", "reason": "Immutable local ID and exact fingerprint excluding that ID." }, "direct-properties": { "status": "required", "reason": "Resource/key scheme/version, source kind, query/filter/visibility/interpretation/schema refs." }, "recognition-observation": { "status": "required", "reason": "Literal evidence-reference identity; no semantic normalization." }, "capabilities-behaviour-actions": { "status": "required", "reason": "New scope for changed interpretation; unpartitioned stream only." }, "context-evidence": { "status": "required", "reason": "One SourceInstance; evidence namespace controlled by host." } }, "RecordSubjectMapping": { "identity-class": { "status": "required", "reason": "Stable claim ID and immutable lineage/target/purpose/issuer anchors." }, "direct-properties": { "status": "required", "reason": "Known qualified key, target kind, validity, evidence and correction predecessor." }, "recognition-observation": { "status": "required", "reason": "Aboutness claim with target-catalogue and pair checks, never same-as." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Append revisions; every activation checks uniqueness; retracted terminal." }, "context-evidence": { "status": "required", "reason": "Authenticated steward with exact map right; catalogue and policy pinned." } }, "SyncEpoch": { "identity-class": { "status": "required", "reason": "Immutable epoch ID within a scope; independent of record generation." }, "direct-properties": { "status": "required", "reason": "Open/closed state, fence, head, local progress and reset evidence." }, "recognition-observation": { "status": "required", "reason": "Progress follows committed sequence; opaque tokens are not ordered." }, "capabilities-behaviour-actions": { "status": "required", "reason": "One open epoch per scope; close after all rounds sealed; reopen with new ID." }, "context-evidence": { "status": "required", "reason": "Admin owns lifecycle; intake transaction alone advances head." } }, "SnapshotRound": { "identity-class": { "status": "required", "reason": "Immutable round ID and scope/epoch/purpose anchors." }, "direct-properties": { "status": "required", "reason": "Consistency, visibility, ordering evidence, pages, errors and completeness." }, "recognition-observation": { "status": "required", "reason": "Strong local key accounting is not proof of actual source completeness." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Append contiguous pages, then seal once; compare only explicit compatible rounds." }, "context-evidence": { "status": "required", "reason": "Source guarantees are host-verified; only proposals arise from absence." } }, "BatchReceipt": { "identity-class": { "status": "required", "reason": "Scope/epoch-wide key and host sequence-derived receipt ID." }, "direct-properties": { "status": "required", "reason": "Exact content, immutable mapping outcomes, counts, previous head and policy revision." }, "recognition-observation": { "status": "required", "reason": "Destination acknowledgement of local metadata only." }, "capabilities-behaviour-actions": { "status": "required", "reason": "One first commit; exact own replay returns old ack; no reapplication." }, "context-evidence": { "status": "required", "reason": "Serialized local journal; current read rights govern receipt disclosure." } }, "RecordOccurrence": { "identity-class": { "status": "required", "reason": "Receipt identity plus original input ordinal, including duplicates." }, "direct-properties": { "status": "required", "reason": "Qualified key, protected content ref, availability operation, times, correction and pin." }, "recognition-observation": { "status": "required", "reason": "Distinguish source-declared acquisition from host receipt and nullable source time." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Immutable; later corrections append evidence without repinning." }, "context-evidence": { "status": "required", "reason": "Part of one receipt; domain truth and subject lifecycle remain external." } }, "QuarantineEntry": { "identity-class": { "status": "required", "reason": "Receipt identity plus original rejected ordinal." }, "direct-properties": { "status": "required", "reason": "Protected descriptor, reason, retry obligation and open state." }, "recognition-observation": { "status": "required", "reason": "Adapter classifies raw failures; this register validates descriptors, not raw bytes." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Retained open in 0.1.0; reingestion is a new batch; resolution API deferred." }, "context-evidence": { "status": "required", "reason": "Host evidence custody and external operational resolution." } }, "ConflictDiagnostic": { "identity-class": { "status": "required", "reason": "Host sequence-derived immutable ID, actor and attempt." }, "direct-properties": { "status": "required", "reason": "Scope/epoch, reason, supplied and retained digests where available." }, "recognition-observation": { "status": "required", "reason": "Restricted operational evidence; not a public existence oracle." }, "capabilities-behaviour-actions": { "status": "required", "reason": "Append on admitted collisions/stale preconditions; no canonical denial telemetry." }, "context-evidence": { "status": "required", "reason": "Privileged archive; a current writer still observes key unavailability." } } }, "factMastership": [ { "fact": "SyncRegister", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "One owned local SQLite master; native snapshots are restricted evidence.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "SourceInstance", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "External source operator owns source truth; host owns its declaration.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "AcquisitionScope", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "One SourceInstance; evidence namespace controlled by host.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "RecordSubjectMapping", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Authenticated steward with exact map right; catalogue and policy pinned.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "SyncEpoch", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Admin owns lifecycle; intake transaction alone advances head.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "SnapshotRound", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Source guarantees are host-verified; only proposals arise from absence.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "BatchReceipt", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Serialized local journal; current read rights govern receipt disclosure.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "RecordOccurrence", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Part of one receipt; domain truth and subject lifecycle remain external.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "QuarantineEntry", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Host evidence custody and external operational resolution.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" }, { "fact": "ConflictDiagnostic", "semanticOwner": "Host source-integration steward", "authoritativeSystem": "One owned local SQLite journal for admitted metadata; external source/domain systems retain their separate authority", "writer": "Authenticated host actor under exact current grants; bootstrap admin for control operations", "readerPurpose": "Exact current scope/purpose read grant; full archive and offline/native functions privileged", "validTime": "Mapping/grant intervals half-open; source-event time nullable; observation/host time and sequence separate", "provenance": "Privileged archive; a current writer still observes key unavailability.", "conflict": "Changed immutable identity rejected; mapping replacement or new occurrence preserves predecessor; no business truth selection", "retention": "Full retained reference history; no erasure or automated quarantine resolution" } ], "catalogue": { "alternateNames": [ "EM-XCT-08", "Sources, bindings and synchronization", "SourceInstance", "RecordSubjectMapping", "SyncEpoch" ], "domain": [ "Enterprise", "Sources and integration" ], "tags": [ "source", "mapping", "synchronization", "checkpoint", "provenance", "quarantine" ], "adoption": "Begin with a declared source, qualified scope and reviewed aboutness mapping to an existing subject. The local reference and three synthetic profiles add atomic metadata receipts, snapshot coverage and a native restricted projection.", "limits": "No live connectors, IAM, business fact application, distributed exactly-once, writable archive import, automated quarantine resolution or production-scale storage. Current host state and protected evidence custody are required." } }