Architecture Attestation

Why it matters

From process claim to cryptographic claim

A "we follow a change process" assertion is an interview answer. A signed attestation is evidence. This is the difference between satisfying an auditor with a binder and satisfying one with a verifier.

Architecture governance moves from a process claim — “we follow a change process” — to a cryptographic claim: here is signed, tamper-evident proof of every governed state.

The auditor doesn't have to take your word for it. They don't even have to take ArchRails' word for it. They run a small open-source verifier against the manifest and the published public key, and the cryptography either checks out or it doesn't.

What an auditor can verify

Three independently-checkable claims

The verifier reads the signed manifest and the published public key. No live ArchRails dependency, no shared credentials, no trust-by-reputation.

🔒

Identity of the signer

The signature is bound to ArchRails' published public key. A forged manifest signed by a different key fails verification immediately.

🗓

Architecture state at a timestamp

The manifest captures the exact architecture that was canonical at a specific commit and time — no drift, no after-the-fact edits.

🧬

Integrity of the change record

Any tampering with the captured architecture, however small, invalidates the signature. The manifest is either intact or it's rejected.

What it evidences

Verifiable proof, on demand

Bring the attestation to your auditor with the verifier output and replace narrative responses with cryptographic ones. The attestation produces evidence that's useful across change-management, integrity, retention, and non-repudiation criteria — wherever your control framework asks for demonstrable proof of architectural change history.

Signed, tamper-evident proof of every architectural change — with the signer's verifiable identity.
Cryptographic hash chain binding each architectural state to the commit it landed on and to the manifest before it. The architecture you say you have is the architecture an auditor can prove you had.
Non-repudiable asymmetric signature. The signer cannot later deny producing the artifact.
Verifiable without us. Your auditor needs no network access to ArchRails, no account, and no reason to trust our dashboard — just the manifest, its signature, and a public CLI.
Per-merge granularity. One signed manifest per governed merge, produced automatically rather than on request.

Specific control-framework mappings are scoped against your audit catalog in evaluation — talk to sales.

What's included

Attestation — included for every deployment.

Not an upgrade, not an add-on, and not something you have to switch on. Every governed merge is attested.

What every merge produces

A signed manifest per promoted architecture state — every change to the canonical graph emits one, automatically.
Chained to the manifest before it — so a silent gap in the record is detectable, not just a missing file nobody notices.
Bound to the commit it landed on — the architecture and the code that shipped it are tied together, not merely adjacent.
Signed by a hardware-backed key — the private key is never exportable and never held by the application.

What your auditor can do with it

Verify it offline — archrails attest verify reads the manifest and its signature from disk. No network. No API. No account.
Install the verifier from public PyPI — it is deliberately ungated, because evidence only you can check is not evidence.
Walk the whole chain — archrails attest verify-chain checks the sequence end to end, so tampering has to defeat every link.
Do it without asking you — nothing above requires your cooperation, your login, or our uptime.

Extended retention horizons and dedicated signing arrangements are scoped per engagement — talk to us about what your regulator asks for.

Customer-managed key custody, full Sigstore-style signature chains, and isolated-key-custody operating modes are available as contract add-ons, scoped per engagement.

Cryptographic proof of every governed architecture state.

From process claim to cryptographic claim

Three independently-checkable claims

Verifiable proof, on demand

Attestation — included for every deployment.

Have an auditor coming and a binder full of process narratives?