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 from CALM definition to deployed artifact. 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.
Long-retention manifests with offline-verifiable signatures — your auditor doesn't need network access to ArchRails to validate.
Per-merge granularity. One signed manifest per governed merge, written to your storage in your AWS account.

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

What's included

Attestation and sovereign signing — included for every deployment.

Nothing here is gated behind an upgrade. Every ArchRails deployment gets both capability sets in full.

Attestation

Signed manifest per promoted architecture state — every PR that changes the canonical graph emits a signed artifact.
Open-source verifier CLI — auditor pip-installs, points it at the manifest, gets a verdict.
In-dashboard verify button — same check inside ArchRails, browser-side, no server round-trip on verify.
Published public key endpoint — the verifier's anchor of trust, cached at the edge.
Seven-year retention — manifest pairs kept for long-horizon regulatory hold requirements.

Sovereign signing

Per-tenant signing key — your own asymmetric key, isolated from every other customer.
Signature-chained manifests — each manifest references the prior one, so silent gaps in the audit trail are detectable.
Transparency-log export — append-only artifact stream for compliance teams who want to mirror the record off-platform.

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 and sovereign signing — included for every deployment.

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