Variable: AUDIT_ACTIONS
constAUDIT_ACTIONS:object
Defined in: packages/contracts/src/schemas/audit-actions.ts:383
The per-action audit payload registry (N171). This is the only place a payload
is defined: an action that is not a key here cannot be recorded, a field that is
not in its payload is refused at the outbox, and adding either is a reviewed change
to @oktoid/contracts. AuditRecorded is the union of one record shape per key,
and verifyAuditSchemas (run by verifyEstate, so by pnpm build) fails when
the two disagree or a payload leaves the identifier vocabulary.
Type Declaration
access.deny
readonlyaccess.deny:object
A refused message. Two payload versions are accepted side by side (29): v1 as slice 1
wrote it, and v2 with version: 2 and actor_token_invalid (D2.2). Each gateway
publishes its own directly, with no outbox (D1.13); every module of credential
whose receiver refuses a message records one on its own pool.
The record's actor is the refused message's actor as claimed, not as verified.
When the reason is actor_token_invalid or actor_unverified, the claim is what
failed, so the sender chose that actor: it says whom the message claimed to act
for, never who acted.
access.deny.outcomes
readonlyoutcomes: readonly ["denied"]
access.deny.payload
readonlypayload:TUnion<[TObject<{messageId:TString;reason:TUnsafe<"tenant_mismatch"|"schema_mismatch"|"unlisted_edge"|"actor_unverified"|"platform_grant_missing"|"scope_denied"|"principal_unknown"|"issuer_not_accepted">;schema:TString; }>,TObject<{messageId:TString;reason:TUnsafe<"tenant_mismatch"|"schema_mismatch"|"unlisted_edge"|"actor_unverified"|"platform_grant_missing"|"scope_denied"|"principal_unknown"|"issuer_not_accepted"|"actor_token_invalid">;schema:TString;version:TLiteral<2>; }>]>
access.deny.producers
readonlyproducers: readonly ["identity","governance","trust","gateway","gateway-admin","issuance","provisioning"]
accreditation.admit
readonlyaccreditation.admit:object
An accreditation was admitted, or, with denied, an admission was refused by a rule
about the decision itself: four eyes (D2.10), where the person who applied tried to
admit, or the display-name rules (security ruling of 2026-10-12). Recording the
refusal is what makes repeated attempts visible.
accreditation.admit.outcomes
readonlyoutcomes: readonly ["success","denied"]
accreditation.admit.payload
readonlypayload:TObject<{accreditationId:TString;fourEyes:TOptional<TBoolean>;frameworkVersion:TInteger;nameConfusable:TOptional<TArray<TString>>;organizationId:TString;reason:TOptional<TUnsafe<"four-eyes"|"name-collision"|"name-script">>; }>
accreditation.admit.producers
readonlyproducers: readonly ["governance"]
accreditation.apply
readonlyaccreditation.apply:object
An organisation was put forward for admission (D2.1). denied is not listed: a
refusal of apply is a scope or state error, which access.deny and the reply carry.
accreditation.apply.outcomes
readonlyoutcomes: readonly ["success"]
accreditation.apply.payload
readonlypayload:TObject<{accreditationId:TString;frameworkVersion:TInteger;organizationId:TString; }>
accreditation.apply.producers
readonlyproducers: readonly ["governance"]
accreditation.publish
readonlyaccreditation.publish:object
Publication was approved: the dated second decision, naming the statements it releases.
accreditation.publish.outcomes
readonlyoutcomes: readonly ["success"]
accreditation.publish.payload
readonlypayload:TObject<{accreditationId:TString;frameworkVersion:TInteger;organizationId:TString;statementIds:TArray<TString>; }>
accreditation.publish.producers
readonlyproducers: readonly ["governance"]
agent.converge
readonlyagent.converge:object
The setup engine converged an agent instance (D3.11), or was refused. A refusal is
recorded with outcome denied and names what was refused in changed:
scheme-refused for the one-way door of 28 section 2, tenancy-refused and
custody-refused for the two other facts of an instance that never change (custody
sets the assurance ceiling of everything the instance issues). The record exists so
that an attempt to walk back through any of them is visible. Until 2026-10-13 the
only outcome was success; no record of a refusal was written under it outside a
development stack.
agent.converge.outcomes
readonlyoutcomes: readonly ["success","denied"]
agent.converge.payload
readonlypayload:TObject<{changed:TArray<TUnsafe<"registries"|"instance"|"scheme-refused"|"tenancy-refused"|"custody-refused">>;instanceId:TString; }> =AgentConvergeAuditPayload
agent.converge.producers
readonlyproducers: readonly ["provisioning"]
anchor.converge
readonlyanchor.converge:object
The anchor was converged by the setup engine (D2.11). An empty changed is a no-op run.
anchor.converge.outcomes
readonlyoutcomes: readonly ["success"]
anchor.converge.payload
readonlypayload:TObject<{changed:TArray<TUnsafe<"statement"|"key"|"framework"|"accreditation"|"four-eyes">>;fourEyes:TOptional<TBoolean>; }>
anchor.converge.producers
readonlyproducers: readonly ["governance"]
audit.checkpoint
readonlyaudit.checkpoint:object
The audit service signed a checkpoint (D3.12), written by the service itself in its
own write path, as audit.record-refused is. The positions it covers and the key's
thumbprint, never the root: the root is in the checkpoint table, chained and
signed, and a second copy here would be a second thing to keep in agreement.
audit.checkpoint.outcomes
readonlyoutcomes: readonly ["success"]
audit.checkpoint.payload
readonlypayload:TObject<{fromSeq:TInteger;keyId:TString;toSeq:TInteger; }> =CheckpointAuditPayload
audit.checkpoint.producers
readonlyproducers: readonly ["audit"]
audit.record-refused
readonlyaudit.record-refused:object
Written by the audit service itself, in its own write path, when it terminates a
message it will never append (09). The record names the refused record's id and
producer where they could be read, and the reason; never the refused body,
which may be exactly what was wrong with it. streamSequence joins it to the
AUDIT stream. A terminated message therefore leaves a trace in the chain, and a
producer that is refused again and again is visible as such.
audit.record-refused.outcomes
readonlyoutcomes: readonly ["denied"]
audit.record-refused.payload
readonlypayload:TObject<{reason:TUnsafe<"tenant_mismatch"|"schema_mismatch"|"subject_unreadable"|"envelope_invalid"|"body_not_json"|"record_invalid"|"payload_hash_mismatch"|"producer_mismatch"|"not_a_producer"|"database_refused"|"not_canonical">;refusedProducer:TOptional<TString>;refusedRecordId:TOptional<TString>;streamSequence:TInteger; }>
audit.record-refused.producers
readonlyproducers: readonly ["audit"]
authentication-identity.link
readonlyauthentication-identity.link:object
authentication-identity.link.outcomes
readonlyoutcomes: readonly ["success"]
authentication-identity.link.payload
readonlypayload:TObject<{subjectId:TString; }>
authentication-identity.link.producers
readonlyproducers: readonly ["identity"]
bootstrap.apply
readonlybootstrap.apply:object
bootstrap.apply.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.apply.payload
readonlypayload:TObject<{anchorCreated:TBoolean;identitiesCreated:TInteger;organizationsCreated:TInteger; }>
bootstrap.apply.producers
readonlyproducers: readonly ["identity"]
bootstrap.plan
readonlybootstrap.plan:object
The setup engine ran in plan mode (D3.11): it reported what an apply would change
and changed nothing. Published straight to JetStream like configuration.apply,
since the runner has no outbox. Recorded because a plan reads the whole desired
state against the live one, which is worth knowing was done and by which run.
wouldRefuse says whether an apply of the same answers would have been refused at
some step (security review of 3.14, F2), so a plan that found a refusal leaves that
on the trail and not only in a terminal. It widens the payload where it stands,
since no producer had filed this action before it (the runner's plan mode arrived
in the same step). It is optional because a required member is not additive under
the registry's compatibility rule: the schema of the recorded-event body would stop
accepting a record the previous version accepted. The one producer, bootstrap's
plan mode, always sets it; a record without it predates this member.
bootstrap.plan.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.plan.payload
readonlypayload:TObject<{driftCount:TInteger;runId:TString;wouldChange:TBoolean;wouldRefuse:TOptional<TBoolean>; }> =BootstrapPlanAuditPayload
bootstrap.plan.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.root-invite
readonlybootstrap.root-invite:object
An installer's command sent the root account's invitation again after setup
(pnpm stack:root-invite; setup-wizard.md, Design 08 items 28 and 29). Its own
action because the setup-step record names the wizard's session as principal, and
this send is the installer's. Published straight to JetStream by bootstrap, like
every setup record. Appended at the end of the registry, as every action is.
bootstrap.root-invite.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.root-invite.payload
readonlypayload:TObject<{principal:TLiteral<"setup:installer">;runId:TString;versionId:TString; }> =RootInvitePayload
bootstrap.root-invite.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-code-burned
readonlybootstrap.setup-code-burned:object
Five wrong codes: the code is dead and the service exits 77 (DW10).
bootstrap.setup-code-burned.outcomes
readonlyoutcomes: readonly ["denied"]
bootstrap.setup-code-burned.payload
readonlypayload:TObject<{attempts:TInteger;forwardedAddress:TOptional<TString>;installerRunId:TString;principal:TLiteral<"setup:root">;socketAddress:TOptional<TString>; }> =SetupCodeBurnedPayload
bootstrap.setup-code-burned.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-code-issued
readonlybootstrap.setup-code-issued:object
The installer registered the first sign-in code, or replaced an unused or burned one.
bootstrap.setup-code-issued.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-code-issued.payload
readonlypayload:TObject<{installerRunId:TString;principal:TLiteral<"setup:installer">; }> =SetupCodeIssuedPayload
bootstrap.setup-code-issued.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-code-reissued
readonlybootstrap.setup-code-reissued:object
The installer's explicit command registered a new code while setup was under way (DW10).
bootstrap.setup-code-reissued.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-code-reissued.payload
readonlypayload:TObject<{installerRunId:TString;principal:TLiteral<"setup:installer">; }> =SetupCodeIssuedPayload
bootstrap.setup-code-reissued.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-completed
readonlybootstrap.setup-completed:object
Setup was completed (DW12). Recorded before the state is committed.
bootstrap.setup-completed.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-completed.payload
readonlypayload:TObject<{engineVersion:TInteger;principal:TLiteral<"setup:root">;versionId:TString; }> =SetupCompletedPayload
bootstrap.setup-completed.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-redeemed
readonlybootstrap.setup-redeemed:object
A code was exchanged for the setup session (DW10).
bootstrap.setup-redeemed.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-redeemed.payload
readonlypayload:TObject<{forwardedAddress:TOptional<TString>;installerRunId:TString;principal:TLiteral<"setup:root">;socketAddress:TOptional<TString>; }> =SetupRedeemedPayload
bootstrap.setup-redeemed.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-reopened
readonlybootstrap.setup-reopened:object
The installer's explicit command reopened a completed setup (DW13).
bootstrap.setup-reopened.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-reopened.payload
readonlypayload:TObject<{fromEngineVersion:TInteger;installerRunId:TString;principal:TLiteral<"setup:installer">;reopenedAtStep:TUnsafe<"anchor"|"identifiers"|"organizations"|"identity-provider"|"accounts"|"key-store"|"configuration">;toEngineVersion:TInteger; }> =SetupReopenedPayload
bootstrap.setup-reopened.producers
readonlyproducers: readonly ["bootstrap"]
bootstrap.setup-step-applied
readonlybootstrap.setup-step-applied:object
The wizard applied one engine step (DW2: every write of the session is audited).
bootstrap.setup-step-applied.outcomes
readonlyoutcomes: readonly ["success"]
bootstrap.setup-step-applied.payload
readonlypayload:TObject<{changed:TBoolean;environment:TOptional<TString>;governingAccount:TOptional<TUnion<[TLiteral<"created">,TLiteral<"present">,TLiteral<"skipped">]>>;identifierMethod:TOptional<TUnsafe<"webvh"|"web">>;invitationSent:TOptional<TBoolean>;principal:TLiteral<"setup:root">;runId:TString;step:TUnsafe<"anchor"|"identifiers"|"organizations"|"identity-provider"|"accounts"|"key-store"|"configuration">;versionId:TString; }> =SetupStepAppliedPayload
bootstrap.setup-step-applied.producers
readonlyproducers: readonly ["bootstrap"]
configuration.apply
readonlyconfiguration.apply:object
The setup engine applied a configuration version (D2.11). Never the document: the version, the one before it (absent on the first apply), the document's hash and how many drift findings the run reported.
configuration.apply.outcomes
readonlyoutcomes: readonly ["success"]
configuration.apply.payload
readonlypayload:TObject<{contentHash:TString;driftCount:TInteger;previousId:TOptional<TString>;supersedes:TOptional<TString>;versionId:TString; }>
configuration.apply.producers
readonlyproducers: readonly ["bootstrap"]
entity-statement.prepare
readonlyentity-statement.prepare:object
A statement was rendered and stored unsigned, awaiting publication (D2.1).
entity-statement.prepare.outcomes
readonlyoutcomes: readonly ["success"]
entity-statement.prepare.payload
readonlypayload:TObject<{accreditationId:TString;exp:TString;keyId:TString;kind:TUnsafe<"entity-configuration"|"subordinate-statement">;statementId:TString; }> =EntityStatementAuditPayload
entity-statement.prepare.producers
readonlyproducers: readonly ["trust"]
entity-statement.publish
readonlyentity-statement.publish:object
A statement was signed and written to the object store (D2.1), or, as denied, the
re-check at signing found its prepared bytes re-rendered since they were last
previewed, so nothing was signed and the statements stay prepared (3a C2).
entity-statement.publish.outcomes
readonlyoutcomes: readonly ["success","denied"]
entity-statement.publish.payload
readonlypayload:TObject<{accreditationId:TString;exp:TString;keyId:TString;kind:TUnsafe<"entity-configuration"|"subordinate-statement">;recordedBy:TOptional<TUnsafe<"approval"|"interrupted-settle"|"renewal-sweep">>;statementId:TString; }> =EntityStatementPublishAuditPayload
entity-statement.publish.producers
readonlyproducers: readonly ["trust"]
entity-statement.renew
readonlyentity-statement.renew:object
A statement was re-rendered and re-signed before half its lifetime ran out (D2.7).
entity-statement.renew.outcomes
readonlyoutcomes: readonly ["success"]
entity-statement.renew.payload
readonlypayload:TObject<{accreditationId:TString;exp:TString;keyId:TString;kind:TUnsafe<"entity-configuration"|"subordinate-statement">;statementId:TString; }> =EntityStatementAuditPayload
entity-statement.renew.producers
readonlyproducers: readonly ["trust"]
framework.publish
readonlyframework.publish:object
A framework version was published (D2.8); digest is the SHA-256 of the published bytes.
framework.publish.outcomes
readonlyoutcomes: readonly ["success"]
framework.publish.payload
readonlypayload:TObject<{digest:TString;version:TInteger; }>
framework.publish.producers
readonlyproducers: readonly ["governance"]
grant.create
readonlygrant.create:object
grant.create.outcomes
readonlyoutcomes: readonly ["success"]
grant.create.payload
readonlypayload:TObject<{bundle:TString;granteeId:TString;organizationId:TString; }>
grant.create.producers
readonlyproducers: readonly ["identity"]
grant.revoke
readonlygrant.revoke:object
A grant ended. A revoke a person asked for through the API carries no cause. One the
platform made carries cause, and a grant ended because the grant it was made under
ended (PO-QA10) also names that grant in causeGrantId, so each record of a cascade
can be followed back to the revoke that started it.
grant.revoke.outcomes
readonlyoutcomes: readonly ["success"]
grant.revoke.payload
readonlypayload:TObject<{cause:TOptional<TUnsafe<"grantee-erased"|"bundle-replaced"|"grantor-revoked"|"holder-replaced">>;causeGrantId:TOptional<TString>; }>
grant.revoke.producers
readonlyproducers: readonly ["identity"]
identifier.converge
readonlyidentifier.converge:object
The setup engine converged issuance (D3.11). An empty changed is a no-op run.
identifier.converge.outcomes
readonlyoutcomes: readonly ["success"]
identifier.converge.payload
readonlypayload:TObject<{changed:TArray<TUnsafe<"identifier"|"probe"|"methods">>; }> =IdentifierConvergeAuditPayload
identifier.converge.producers
readonlyproducers: readonly ["issuance"]
identifier.create
readonlyidentifier.create:object
An identifier was created for an organisation, in placing (D3.3).
identifier.create.outcomes
readonlyoutcomes: readonly ["success"]
identifier.create.payload
readonlypayload:TObject<{host:TString;identifierId:TString;instanceId:TOptional<TString>;organizationId:TString;version:TInteger; }> =IdentifierAuditPayload
identifier.create.producers
readonlyproducers: readonly ["issuance"]
identifier.key-discard
readonlyidentifier.key-discard:object
issuance had the agent destroy keys of an identifier, and the agent confirmed it
(slice 3, plan 3a, rulings 1 and 2). Written in the transaction that records the
discard, so a key that is gone always has a record saying which identifier it
belonged to and why it went: spent for an update key whose entry is durable,
unpublished for keys of a document that was never published. Thumbprints, never
handles. Appended at the end of the registry, as every action is.
identifier.key-discard.outcomes
readonlyoutcomes: readonly ["success"]
identifier.key-discard.payload
readonlypayload:TObject<{identifierId:TString;keyIds:TArray<TString>;reason:TUnsafe<"spent"|"unpublished">; }> =IdentifierKeyDiscardAuditPayload
identifier.key-discard.producers
readonlyproducers: readonly ["issuance"]
identifier.prepare
readonlyidentifier.prepare:object
Its keys were generated in the custodian and its document rendered for preview, or,
as denied, the agent refused to generate them and nothing was rendered.
denied and the payload's reason were added by step 3.2d, in place and not as a
second member of AuditRecorded: no producer had written a record of this action
yet, which is the one moment 29's freeze leaves an audit literal free to widen (the
precedent is entity-statement.publish gaining denied, not access.deny v2,
which had records to keep).
identifier.prepare.outcomes
readonlyoutcomes: readonly ["success","denied"]
identifier.prepare.payload
readonlypayload:TObject<{host:TString;identifierId:TString;instanceId:TOptional<TString>;organizationId:TString;reason:TOptional<TUnsafe<"agent-refused">>;version:TInteger; }> =IdentifierPrepareAuditPayload
identifier.prepare.producers
readonlyproducers: readonly ["issuance"]
identifier.publish
readonlyidentifier.publish:object
A version of an identifier was written out and resolves, or, as denied, it was
not: what the agent signed was not the previewed document (D3.3), the delegated
host does not point at this deployment (the control rule), the agent refused to
sign, or another identifier was published on the host first. Nothing is written on
a denial. A first publication that fails its gate leaves the identifier failed.
An update that fails its gate is identifier.update denied, never this action.
Two payload shapes are accepted side by side (29), as for access.deny. Producers
write the second, which names each key by its part; the first is the shape
registered before the ruling on pre-rotation and is kept because schemas only grow.
Both are in audit-issuance.ts, with what each field means on a denied record.
identifier.publish.outcomes
readonlyoutcomes: readonly ["success","denied"]
identifier.publish.payload
readonlypayload:TUnion<[TObject<{did:TString;identifierId:TString;keyIds:TArray<TString>;version:TInteger;versionId:TOptional<TString>; }>,TObject<{assertionKeyIds:TArray<TString>;commitsTo:TOptional<TString>;did:TOptional<TString>;identifierId:TString;method:TUnsafe<"webvh"|"web">;reason:TOptional<TUnsafe<"document-mismatch"|"agent-refused"|"host-unverified"|"host-taken">>;signedBy:TOptional<TString>;version:TInteger;versionId:TOptional<TString>; }>]>
identifier.publish.producers
readonlyproducers: readonly ["issuance"]
identifier.update
readonlyidentifier.update:object
An update began: a new assertion key, and the identifier back in prepared. As
denied, the update did not happen: the agent refused, or signed something other
than the previewed document, and the identifier stays published as it was (plan
3a, the ruling on a failed update gate). Widened by step 3.2d on the same footing as
identifier.prepare above.
identifier.update.outcomes
readonlyoutcomes: readonly ["success","denied"]
identifier.update.payload
readonlypayload:TObject<{host:TString;identifierId:TString;instanceId:TOptional<TString>;organizationId:TString;reason:TOptional<TUnsafe<"document-mismatch"|"agent-refused"|"host-unverified">>;version:TInteger; }> =IdentifierUpdateAuditPayload
identifier.update.producers
readonlyproducers: readonly ["issuance"]
identity-provider.converge
readonlyidentity-provider.converge:object
One record per realm a run changed (PO2). No target; setting codes, never values.
identity-provider.converge.outcomes
readonlyoutcomes: readonly ["success"]
identity-provider.converge.payload
readonlypayload:TObject<{changed:TArray<TUnsafe<"smtp"|"realm"|"access-token-lifespan"|"id-token-lifespan"|"authorization-code-lifespan"|"refresh-token-lifespan"|"sso-session-lifespan"|"password-policy"|"brute-force"|"internationalisation"|"required-actions"|"client"|"client-scope"|"audience-mapper"|"direct-access-grants"|"root-account"|"client-disabled"|"invitation-mail">>;realm:TUnsafe<"staff"|"holders">; }> =IdentityProviderChange
identity-provider.converge.producers
readonlyproducers: readonly ["identity"]
person.invite
readonlyperson.invite:object
person.invite.outcomes
readonlyoutcomes: readonly ["success"]
person.invite.payload
readonlypayload:TObject<{providerUserLinked:TBoolean;realm:TUnsafe<"staff"|"holders">; }>
person.invite.producers
readonlyproducers: readonly ["identity"]
person.reinvite
readonlyperson.reinvite:object
Someone asked for a person to be invited again, or for the first time after a
create without invite (PO-QA8). previous is where the earlier invitation stood.
The mail itself is person.invite, recorded when it goes out.
person.reinvite.outcomes
readonlyoutcomes: readonly ["success"]
person.reinvite.payload
readonlypayload:TObject<{previous:TUnsafe<"failed"|"none"|"sent">;realm:TUnsafe<"staff"|"holders">; }>
person.reinvite.producers
readonlyproducers: readonly ["identity"]
placement.create
readonlyplacement.create:object
A subject was placed on an agent instance (D3.6). Placements are append-only.
placement.create.outcomes
readonlyoutcomes: readonly ["success"]
placement.create.payload
readonlypayload:TObject<{instanceId:TString;state:TUnsafe<"active"|"draining"|"retired">;subjectId:TString; }> =PlacementCreateAuditPayload
placement.create.producers
readonlyproducers: readonly ["provisioning"]
placement.quota-held
readonlyplacement.quota-held:object
provisioning held a placement request because the quota of new placements per
window was reached (slice 3, step 3.10b; 3a, the consumed event as a trust
boundary). Written once per window, the first time the window holds, and filed under
platform: the quota is the estate's, not a tenant's, and the record names no
organisation, since the one whose request happened to be held is not the cause.
Numbers only: the limit, the window, and how many placements the window held.
The plan wrote the name as placement.quota_held; an action name takes no
underscore, so it is placement.quota-held, as audit.record-refused is.
placement.quota-held.outcomes
readonlyoutcomes: readonly ["denied"]
placement.quota-held.payload
readonlypayload:TObject<{perWindow:TInteger;placed:TInteger;windowSeconds:TInteger; }> =PlacementQuotaHeldAuditPayload
placement.quota-held.producers
readonlyproducers: readonly ["provisioning"]
registry.probe
readonlyregistry.probe:object
The setup engine's throwaway write to a registry succeeded and read back (D3.11).
registry.probe.outcomes
readonlyoutcomes: readonly ["success"]
registry.probe.payload
readonlypayload:TObject<{changed:TArray<TUnsafe<"identifier"|"probe"|"methods">>;registry:TUnsafe<"centralized">; }> =RegistryProbeAuditPayload
registry.probe.producers
readonlyproducers: readonly ["issuance"]
signing-key.generate
readonlysigning-key.generate:object
A key was generated in the custodian (D2.4, D2.7). The handle is not recorded.
signing-key.generate.outcomes
readonlyoutcomes: readonly ["success"]
signing-key.generate.payload
readonlypayload:TObject<{keyId:TString;purpose:TString; }>
signing-key.generate.producers
readonlyproducers: readonly ["trust"]
signing-key.register
readonlysigning-key.register:object
The audit service recorded a checkpoint signing key in audit.signing_key (slice 3,
step 3.8b), written by the service itself in the same transaction as the
registration, as audit.checkpoint and audit.record-refused are written by it.
Appended at the end of the registry, as every action is: the order is published.
The aggregate is the signing key, as in signing-key.generate, which trust
records for a key it generates; this one is the audit service's own key. The key's thumbprint and nothing else: the handle is an address on a
token and the public key is in the table, under an id the database checks.
It exists because the audit writer's role can register any key it likes. With this
record, a key that signs a checkpoint has a registration that the chain itself
holds, at or before the last record that key's first checkpoint covers;
verify-chain --checkpoints reports a key without one. It does not by itself stop
someone who can append records, which is why verification is also pinned to a
thumbprint kept outside the database (--expect-key).
signing-key.register.outcomes
readonlyoutcomes: readonly ["success"]
signing-key.register.payload
readonlypayload:TObject<{keyId:TString; }> =SigningKeyRegisterAuditPayload
signing-key.register.producers
readonlyproducers: readonly ["audit"]
subject-key.destroy
readonlysubject-key.destroy:object
Erasure by key destruction (D1.9). The target is the subject; nothing personal is, or could be, recorded.
subject-key.destroy.outcomes
readonlyoutcomes: readonly ["success"]
subject-key.destroy.payload
readonlypayload:TObject<{ }>
subject-key.destroy.producers
readonlyproducers: readonly ["identity"]
subject-key.rewrap
readonlysubject-key.rewrap:object
Subject keys were re-wrapped under another key-encryption key (D3.14). Never one record per key: subject keys are interchangeable for this purpose, so 09's batch rule applies, and a record per subject would say only that a subject exists.
A record covers the keys one batch moved from one source key to the target, and is
written in the transaction that moved them, so a run killed half way leaves no moved
key without a record. A run is its records taken together, joined by the correlation
id they share. count is the keys this record's batch moved, not the run's total.
unwrapFailed is how many keys the batch found under fromKekId and could not open,
and so left where they were. It is absent when there were none. A key that cannot be
opened is damaged or was wrapped under something else than its row says; either way
the subject's data is unreadable until someone looks, which is why it is counted here
and not only logged.
subject-key.rewrap.outcomes
readonlyoutcomes: readonly ["success"]
subject-key.rewrap.payload
readonlypayload:TObject<{count:TInteger;fromKekId:TString;toKekId:TString;unwrapFailed:TOptional<TInteger>; }>
subject-key.rewrap.producers
readonlyproducers: readonly ["identity"]
subject.create
readonlysubject.create:object
subject.create.outcomes
readonlyoutcomes: readonly ["success"]
subject.create.payload
readonlypayload:TObject<{kind:TUnion<[TLiteral<"organization">,TLiteral<"person">]>;path:TString; }>
subject.create.producers
readonlyproducers: readonly ["identity"]