Access Audit

Findings

Catalogue-native findings must describe the information grouped by each layer. This legacy version does not declare them separately.

Questions & artifacts

Questions, artifact requirements and serial naming rules are required by Vercy vNext; they remain unassigned in this reference version.

Dimension & namespace

• REFERENCE `world.ownership` (S1): entries name registered objects, and owner visibility resolves through ownership records.
• REFERENCE `world.accessContract` (S2): permitted events cite the contract exercised; the log is the contract's execution history.
• REFERENCE `world.disclosureScope` (S3): each disclosure entry carries the policy version and template fingerprint that shaped it.
• REFERENCE `world.accessEnforcement` (S7): the log is the primary evidence source for violation signals and enforcement cases.
• imports: merkle-logs (COMPOSE): the tree structure underlying anchors and inclusion proofs.
• imports: mu-event (EXTEND): the event primitive that access events specialize.
• imports: rfc-9162 (ALIGN): the verifiable-log pattern of published anchors and third-party auditability.

Canon, patches & standards

• REFERENCE `world.ownership` (S1): entries name registered objects, and owner visibility resolves through ownership records.
• REFERENCE `world.accessContract` (S2): permitted events cite the contract exercised; the log is the contract's execution history.
• REFERENCE `world.disclosureScope` (S3): each disclosure entry carries the policy version and template fingerprint that shaped it.
• REFERENCE `world.accessEnforcement` (S7): the log is the primary evidence source for violation signals and enforcement cases.
• imports: merkle-logs (COMPOSE): the tree structure underlying anchors and inclusion proofs.
• imports: mu-event (EXTEND): the event primitive that access events specialize.
• imports: rfc-9162 (ALIGN): the verifiable-log pattern of published anchors and third-party auditability.

Artifact formats & serial data

Format-independent core. Concrete artifact formats and naming prefixes are not declared in this legacy version.

Policies & accepted processes

• `ownerAuditFeed`: the owner of any object receives, on demand or by subscription, every entry that touched their objects.
• `oversightExtract`: the audit registrar provides aggregate, identity-free extracts for systemic oversight of access patterns.
• `proofService`: any party obtains anchors and inclusion proofs to verify log integrity without reading entry contents.

Read / add / edit / delete

CRUD procedures and interface bindings are not declared in this legacy version.

Ownership, roles & access

An audit registrar archetype operates the log but owns none of its content: it may not read entry payloads beyond what operation requires, and it cannot amend them at all. The standing beneficiary is the data owner, whose right to their own timeline is not itself contract-gated, while all other access follows S1/S2.

Objects

• `accessEvent`: one read, grant, revocation or denial; key attributes: time, reader reference, object reference, contract reference, outcome.
• `auditEntry`: the sealed ledger record wrapping one or more events; key attributes: sequence number, content hash, previous-entry hash.
• `merkleAnchor`: a periodically published root hash committing a range of entries; key attributes: root, range, publication time, publication channel.
• `inclusionProof`: the proof that a given entry is committed by an anchor; key attributes: path, anchor reference, verified state.
• `readerAttribution`: the resolved actor behind a read (person, organization, system, agent); key attributes: actor reference, acting capacity, authentication basis.
• `denialRecord`: a refused access attempt; key attributes: requested scope, refusal reason, requester.
• `retentionRule`: how long entries stay queryable in detail; key attributes: class of entry, retention period, sealing condition.

Relationships

• `auditEntry` -> seals -> `accessEvent` (1..*): events become immutable once wrapped in an entry.
• `auditEntry` -> chainedTo -> `auditEntry` (1..1): each entry commits its predecessor's hash, making insertion and deletion detectable.
• `merkleAnchor` -> commits -> `auditEntry` (1..*): anchors let outsiders verify the log without reading it.
• `inclusionProof` -> provesMembershipOf -> `auditEntry` (1..1): any party can check an entry against a published anchor.
• `accessEvent` -> exercised -> `accessContract` (0..1): permitted reads cite the S2 contract they ran under; denials may cite none.
• `accessEvent` -> touched -> `registryEntry` (1..*): every event names the S1-registered objects involved.

Events

• `readRecorded`: a permitted read of someone's data was written to the log.
• `grantRecorded`: the creation, amendment or revocation of an access contract was written to the log.
• `denialRecorded`: an attempted read was refused and the refusal preserved.
• `entrySealed`: a batch of events was wrapped, hashed and chained.
• `anchorPublished`: a root hash for a range of entries was made public.
• `proofIssued`: an inclusion proof was produced for a challenged entry.
• `inconsistencyDetected`: a verification failed, indicating tampering or loss between entries and anchors.

Projections

• `ownerTimeline`: who read my data, when, under which contract; omits every other owner's entries.
• `readerActivitySummary`: aggregate read counts and patterns per reader; omits the identities of touched objects and owners.
• `integrityBundle`: anchors, chain heads and proofs only; omits all event payload.