30-Day SDC Audit / The audit period

The audit period

What runs, what gets logged, and what to expect across the 30 days.

What runs

sdcgovernance sits next to your decision flow as an observation layer. Every time a decision occurs, the engine evaluates the DMN decision table you authored against the SDC instance involved, reading rule inputs from the ProvGov layer (risk score, classification, actor role, attestation status, retention class) and provenance evidence from the same layer (system, activity, party, validation hashes). The outcome is a Receipt: a structured, hash-chained record of the decision, the rule that fired, and the substrate state at the moment of evaluation.

Each SDC instance the engine reads was populated by the team from the template the on-ramp produced, validated on import, and now lives in the generated app's knowledge graph.

The audit is observational by design. sdcgovernance does not gate, block, or modify your existing decision flow during the pilot. The Receipts capture what would have happened under structural enforcement without requiring you to flip the enforcement switch.

What gets logged on every decision

  • decision: PERMIT, DENY, INDETERMINATE, or NOT_APPLICABLE (XACML 3.0)
  • reasoning: which rule fired and why
  • status_code: a XACML URN for evaluation status
  • instance_id and instance_version: the SDC instance evaluated
  • timestamp: when the decision happened
  • previous_hash: the receipt_hash of the prior Receipt in the chain
  • dimensions_checked: which fields the rule looked at, named by their ProvGov component identifiers
  • errors: any evaluation problems
  • context_hash: SHA-256 of the evaluation context that produced the decision (covers the ProvGov state the rule read)
  • receipt_hash: SHA-256 of the Receipt content (RFC 8785-aligned canonicalization)

The Receipt does not duplicate the ProvGov layer; it references it. dimensions_checked names the ProvGov components the rule consumed (provenance activity, attestation, party role, access level, retention class). context_hash covers their state at evaluation time. The entity-state-before and entity-state-after hashes from the Validation Details ProvGov family give the chain its tamper-evidence: change a historical record and the next Receipt's previous_hash no longer matches.

The day-by-day rhythm

Days 1-3: Setup and first traces

Substrate is in place from the prerequisites and on-ramp pages, with both domain and ProvGov components composed into the model. sdcgovernance is installed. The DMN decision table is authored and version-controlled. First Receipts begin appearing in the chain. Verify shape and bindings: dimensions_checked should name the ProvGov components the rule was supposed to read.

Days 4-7: Steady-state observation

Receipts accumulate. The chain grows linearly with the decision flow's volume. No human attention required day-to-day. Schema drift detection (if SDC Agents SMB is wired in for ongoing introspection) flags any changes the team did not announce.

Days 8-21: Continuous accumulation

Receipt corpus grows. INDETERMINATE outcomes accumulate as the most informative diagnostic signal: they mark places where the rule could not reach a definitive PERMIT or DENY. Each one is a candidate gap to investigate at the readout.

Days 22-29: Pre-readout review

Optional: skim the Receipt corpus for surprises before the formal day-30 readout. Run verify_chain() to confirm chain integrity. Spot-check a handful of receipts against the source data they reference.

Day 30: The readout

Aggregate the corpus. Answer the three audit questions (next page). Write up the gap-free or gap-found findings. The chain itself is the audit trail; the readout is the summary for the board.

Operating posture

  • Read-only against the existing decision flow. The pilot does not change production behavior.
  • Hash chain is append-only. Each Receipt's previous_hash links back to the prior. Tampering with a historical Receipt invalidates every Receipt downstream.
  • Storage requirements are modest. A typical Receipt is 1-2 KB serialized. A decision flow processing 1,000 decisions per day produces roughly 30-60 MB of Receipts across the 30 days. Persist to local disk, S3, or a SQL table as the team prefers.
  • No human attention required during steady-state. If the substrate is right and the DMN table reflects intended rules, the audit accumulates evidence without ongoing operational work.
Previous: Choose your on-ramp Next: Reading the results