1. Docs
2. Concepts

Evidence and Audit

Imported compliance evidence, the hash-chained audit log, and the signed evidence pack a third party can verify — evidence, never assurance.

#Evidence, Not Assurance

Archigov never states that you are compliant with anything. It shows evidence and who stands behind it: what was observed, by which source, when, and which human verified, decided or excepted what. Every export carries the same disclaimer.

#Imported Evidence

Resource-level security and configuration checks are imported, not rebuilt:

Each item is stored as evidence on a resource: a control key, a state (pass, fail or unknown), the observation time, the source's severity and detail. Imports upsert by resource, source and control. Assessments the default mapping does not know keep a source-prefixed key (defender:<slug>, policy:<definitionName>); a platform admin can map them under Settings → General (evidence.control_map), with AI suggestions if enabled.

Rules consume evidence with op: evidence. A resource with no evidence for the control is a finding — no evidence imported — never a pass.

Note

Subscription-scoped assessments (for example Defender recommendations whose target is the subscription itself) do not attach to a resource and are reported as unmatched.

#The Audit Log

Everything that matters writes an audit row: submissions, positions, resolutions, declarations, adoptions, exceptions, finding closures, verifications, reaffirmations, risks logged and changed, imports, setting changes, sign-ins. Each row carries the actor, their role, the entity and its human code, the details, and two hashes:

• prev_hash — the hash of the previous row;
• hash — SHA-256 over this row's content and prev_hash.

The rows form a hash chain. Changing or deleting any row breaks every hash after it. GET /api/audit/verify re-computes the chain and reports the first break, if any. Secrets are never written to the audit log: a changed key is recorded as set, cleared or kept.

#The Evidence Pack

The evidence pack is a single JSON document — tenant-wide or for one application. It records the generation time, the scope and the disclaimer, the verification coverage of the model, and for each application its classification (with its origin, reason and who verified it), its legacy standing (its legacy components and the latest legacy assessment, with who recorded it and until when it is valid), its third parties (each provider, whether it is a designated critical third party, and the latest exit plan with its substitutability, who recorded it and until when it is valid), its resources (with provenance, verification, content hash and imported evidence), its decisions (with constraints and dependency links), its reviews (positions, resolutions, approvals, assessments and conditions) and its findings. It lists every catalogue artefact with its control references, lifecycle, whether it is checkable and how many findings are open; the risk register in scope — every risk for the tenant, or the risks that name the application — with each risk's severity, status, source, owner, review date, the decision that accepts it, its origin and any closing note; the board sessions with their minutes hashes; and the audit trail with the chain head.

It is serialised as canonical JSON, hashed with SHA-256, and signed with the instance's Ed25519 key. The public key is published in the product (Audit Log page and Settings) so anyone can check a pack:

1. Export the pack (authors, auditors, board seats and the platform admin can).
2. Call GET /api/evidence-pack/verify?hash=<sha256> on the instance, which re-checks the hash, the signature and the audit chain head — or verify the Ed25519 signature independently with the published public key.

Persisted packs are kept under DATA_DIR/evidence-packs. The signing key pair lives in DATA_DIR/keys/ (evidence-signing.key mode 0600, .pub mode 0644).

A board pack — the governance figures a board's chair or secretary prepares for a sitting, with the decisions decided in the period and the risks needing attention — is hashed, anchored to the audit chain, signed and kept by the same code, so the same GET /api/evidence-pack/verify?hash= call, or the same independent check, verifies it.

#Other Exports

• OSCAL 1.1.2 assessment results — findings and observations in NIST's machine-readable format.
• DORA register of information — a clearly labelled, simplified CSV of ICT third-party dependencies; criticality comes from each application's classification and stays blank where nobody has classified it or the tier is important, because whether that tier is a DORA important function is your organisation's call; substitutability comes from the latest exit plan and stays blank without one; suppliers named on resource tags get rows of their own; codes a human must supply are left blank.
• ArchiMate Open Exchange — the generated views, which open in Archi.

See Exports for formats and endpoints.

#Who Sees What

Every signed-in user can read. Exports are open to authors, auditors, every board seat and the platform admin; service accounts and users with no role read only. Nobody can edit or delete audit rows through the product.

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.