Project History

Genesis Mesh has shipped a sequence of tagged releases since v0.1.0. This page provides a high-level timeline and links to the per-phase detail pages. Each phase page names the question the phase answered, what changed, what guarantees were added, and what became possible.

The canonical sources behind this document are the per-release plans under ops/, the architectural thesis in Genesis Mesh Strategy, and the project VISION.md.

1. The Problem

The September 2026 public reference deployment hardening separates a keyless, read-only dashboard from local signing and maintenance. Fresh neutral identities replace the public legacy dataset while original signed records remain in an offline archive. Signed snapshots bind current relationships, heartbeat imports and canary evidence; the dashboard distinguishes service readiness from trust posture. See Sanitized public reference dashboard for verification and the boundaries of the single-node reference demonstration.

Machines can connect. They cannot prove trust.

Every AI agent, autonomous system, and distributed worker that talks to another one today answers three questions badly or not at all:

  • Who is this? Is this agent who it claims to be, or an impostor on a flat, anonymous network?

  • What can it do? What is it actually authorized to do, and under whose policy?

  • How do I cut it off? When it is compromised, how do I revoke it everywhere, instantly, with proof?

Identity and access systems exist. They live inside one provider (Entra ID, Okta, IAM) or one consortium (verifiable credentials, DIDs). None of them carry trust across independent organizations the way DNS carries names or PKI carries certificates. Most agent frameworks silently assume this layer is solved. It is not.

Genesis Mesh is intended to be that layer: a protocol for sovereign communities to establish, delegate, recognize, and revoke trust across organizational boundaries. The core primitive is portable trust. Capabilities, agents, workflows, marketplaces, and economies are overlays on top of it.

The long-term value is not only the code; it is the recognition network: the accumulated graph of who recognizes whom. Code can be copied; relationships cannot.

2. The Journey, in Phases

Ten phases, each answering one open question.

Phase

Versions

Theme

Detail

A

v0.1.0 – v0.5.2

Foundation

Phase A – Foundation

B

v0.6.0 – v0.8.0

Agent Layer

Phase B – Agent Layer

C

v0.9.0 – v0.12.0

The Trust Thesis

Phase C – The Trust Thesis

D

v0.12.1

Operational Proof

Phase D – Operational Proof

E

v0.13.0 – v0.17.11

Operator Readiness

Phase E – Operator Readiness

F

v0.18.0 – v0.21.0

Multi-Cloud Operation

Phase F – Multi-Cloud Operation

G

v0.22.0 – v0.25.0

Application Layer

Phase G – Application Layer

H

v0.26.0 – v0.31.0

Governed Relationships

Phase H – First Complete Trust Architecture Cycle

I

v0.32.0 – v0.37.0

Runtime Trust Layer

Phase I – Runtime Trust Layer

J

v0.38.0 – v0.52.1

Third Trust Cycle + Maturity

Phase J – Third Trust Cycle

The arc: Phase A proved authenticated routing is possible. Phases B–D proved it carries real workloads and crosses real cloud boundaries. Phases E–G made it operable, multi-cloud, and legible to non-protocol readers. Phase H built the complete trust architecture cycle — dual-signed agreements, delegation chains, gated authorization, tamper-evident execution, bounded freshness, and machine-checked lemmas. Phase I made those relationships usable at runtime — bearer tokens, human oversight, selective disclosure, consensus authorization, and peer risk signals. Phase J hardened the full pipeline against adversarial behavior and formally verified the remaining open properties.

3. Patterns of Discipline

Across every shipped release, several patterns held without exception.

Every plan has the same structure. Goal/Positioning, Release Narrative, Success Criteria, In Scope / Out of Scope, Implementation Phases, Verification, Release Gate. A reader can pick up any plan and navigate it.

Every plan has an Out-of-Scope section. From v0.1 onward, marketplaces, billing, tokens, governance UI, reputation scoring, registry monetization, and global discovery are explicitly named as not-this-release. v0.8 says cross-sovereign trust is out (rightly — that was v0.9). v0.10 says transitive recognition is out. v0.14 says marketplace and paid billing are out.

Release Gates are real checklists. Not “we hope this works” but “do not tag until X.” Most releases have Verified Results blocks with specific test counts (215 passed, 228 passed, 236 passed), specific mypy output, and demo confirmation.

Honesty is structural. v0.9 says explicitly that the first proof is operated by the maintainer on two NAs and the demo must say so. v0.12.1 says “the important claim is not ‘two services are online,’” naming what the proof is and is not. v0.14 CHANGELOG says the external adoption milestone still requires an external operator.

Protocol-vs-platform discipline never broke. Across every shipped release, no release drifted into building a marketplace, a token economy, a central reputation system, or a closed registry. The Out-of-Scope sections held the line at every step.

The recovery from v0.14 is the most informative single artifact. When reality didn’t match the plan, the response was: rename the release to be honest about what shipped, write a CHANGELOG note that acknowledges the original goal is still open, and keep external adoption proof separate from maintainer-operated evidence.

4. What Is True Today

As of v0.60.0:

  • A working permissioned mesh runs in production on Azure, with cryptographic identity, signed join certificates, Noise XX peer sessions, CRL enforcement, peer discovery, and routing.

  • A cooperative multi-agent workflow runs on top of it with measured capacity baselines.

  • Capability discovery and trust-aware orchestration with revocation failover are demonstrated end-to-end.

  • Portable trust between independent sovereigns works in code: signed membership attestations, signed recognition treaties, treaty-backed acceptance, signed revocation feeds, cross-boundary revocation propagation, and a recognition-graph export.

  • The Connectome surfaces the recognition graph with trust-path explanations and revocation blast-radius summaries, as one view over signed protocol data.

  • Maintainer-operated sovereigns run across Azure, DigitalOcean, Cloudflare, and Akamai/Linode with separate identities, keys, endpoints, policies, and public trust material.

  • Separate sovereign deployments have successfully recognized each other and propagated revocation across real network boundaries.

  • A reproducible operator packet exists, including a quickstart, a security checklist, a recognition playbook, and a proof bundle schema. The proof bundle format distinguishes maintainer-operated infrastructure from externally-operated infrastructure.

  • The Network Authority can run as several instances on a shared PostgreSQL database behind a load balancer. Losing an instance loses no decision, revocation or evidence, and every exactly-once operation is enforced by the database.

  • The project is open-source, MIT-licensed, and installable from PyPI as pip install genesis-mesh.

  • Every shipped release has a written plan in ops/ and a verified release gate.

  • All three trust architecture cycles are shipped: governed relationships (v0.26–v0.31), runtime trust layer (v0.32–v0.37), and adversarial hardening with formal verification (v0.38–v0.48).

  • Eight security lemmas are machine-checked in Tamarin Prover across the full pipeline and the PeerRiskSignal state machine.

  • 1,088 tests pass. The layer rule and public boundary rule are enforced in code and documented in AGENT.md.

  • 25 animated terminal GIF demos cover every protocol feature across all three phases, with shared rendering and bootstrap infrastructure.

  • Structured issue templates, a PR template, CODEOWNERS, a full contributor guide, and a release checklist make the project legible to contributors who did not write it.

  • A versioned public API stability contract is declared in docs/stability.md, with a formal deprecation policy in DEPRECATION_POLICY.md.

  • A protocol conformance suite exists in conformance/: 9 suites, 11 deterministic vectors, a reference runner, and a pytest integration.

  • All SDK-required stable protocol operations are exposed over HTTP via 6 new NA route blueprints (agreement, boundary, evidence, disclosure, consensus, data usage), with a full HTTP reference at docs/api/trust-http.md.

  • Boundary authorization rules are signed, versioned configuration: a BoundaryPolicy configures gate types from a frozen, code-defined GateRegistry, and every policy-aware BoundaryDecision signs a PolicyBinding naming the exact policy versions, gate order and outcomes that produced it, failing closed on any policy, gate or context error, with Declarative Boundary Policy.

  • Boundary decisions can rest on membership instead of agreement: an AttestationBinding signs the digest, subject, issuer and checked revocation-feed sequence of the MembershipAttestation a request was evaluated under, so revoking the attestation locally or through an imported feed denies every later request, with Example: Attestation-Backed Boundary Evaluation.

  • The Network Authority can be the durable audit record: with the evidence store on, it keeps every decision it signs and the signed execution evidence controllers submit, in an append-only hash chain with one verifiable history per secret, with Example: Evidence Store in the Network Authority.

Phase K — v0.53.0: TypeScript SDK (June 2026)

Question this phase answered: Can a TypeScript developer verify trust and check boundary authorization against a Genesis Mesh Network Authority using strongly-typed async functions, with no Python knowledge required?

What changed:

A standalone TypeScript SDK was created at sdk-typescript/ (decoupled from the Python repo, at C:\Source\GenesisMeshLabs\sdk-typescript\). The SDK is the first external-language client for the Genesis Mesh Trust API.

  • GenesisMeshClient facade with 7 sub-clients covering the complete stable HTTP surface introduced in v0.51–v0.52: agreement, boundary, evidence, attestation, disclosure, consensus, dataUsage.

  • src/auth.ts — pure functions for admin authentication: canonicalJson (byte-for-byte compatible with Python’s json.dumps(..., sort_keys=True, separators=(",",":"))), Ed25519 signing via Node.js built-in crypto, and buildAdminHeaders that produces the four X-Admin-* headers consumed by all admin NA routes.

  • src/types.ts — 30+ TypeScript interfaces mirroring the Pydantic models for all stable protocol objects (agreements, decisions, evidence, proofs, policies, intents, nullifiers, votes).

  • src/errors.ts — typed error hierarchy: GenesisMeshError, UnauthorizedError, ValidationError, NotFoundError, RateLimitError, NetworkError, BadRequestError.

  • 74 Jest tests (9 suites), all passing. Tests use a mock fetch injection rather than a running NA, making them fast and CI-friendly.

  • Build targets: ESM (dist/esm/) + CJS (dist/cjs/) + type declarations (dist/types/). Zero runtime dependencies.

What became possible:

  • TypeScript/JavaScript developers can now interact with any Genesis Mesh NA without a Python environment.

  • Admin operations (offer, decide, build-evidence, commit, vote, etc.) are fully typed and handle Ed25519 request signing transparently.

  • Verify operations (agreement, boundary, evidence, proof, consensus, data usage) require no signing key and can be called from browser or edge environments.

  • The SDK repo structure establishes the decoupling pattern for Go SDK (v0.54), C# SDK (v0.55), and subsequent language implementations.

As of v0.53.0, the following are not yet true:

  • Genesis Mesh does not yet have Go or C# SDKs.

  • A second independent implementation has not yet been built.

  • No external operator has yet run a sovereign with their own infrastructure account, keys, policy, endpoint, and continuity responsibilities.

Phase L — v0.54.0: Go SDK (June 2026)

Question this phase answered: Can a Go developer issue trust decisions, build membership attestations, and verify boundary authorization against a Genesis Mesh Network Authority using idiomatic Go — no Python, no CGO, no third-party dependencies?

What changed:

A standalone Go SDK was created at sdk-go/ (module path github.com/GenesisMeshLabs/sdk-go/genesismesh). The SDK is stdlib-only and passes the Go race detector.

  • Client facade with 7 sub-clients covering the complete stable HTTP surface: Agreement, Attestation, Boundary, Consensus, DataUsage, Disclosure, Evidence.

  • auth.go — pure Go implementation of canonical JSON (byte-for-byte compatible with the Python and TypeScript implementations), Ed25519 signing via crypto/ed25519, and BuildAdminHeaders producing the four X-Admin-* headers consumed by all admin NA routes.

  • types.go — 20+ Go structs with json tags mirroring the Pydantic models for all stable protocol objects.

  • errors.go — typed error hierarchy: APIError, UnauthorizedError, ValidationError, NotFoundError, RateLimitError, ServerError, NetworkError.

  • 19 unit tests passing with -race, using httptest.Server for mock HTTP — no running NA required.

  • Zero runtime dependencies — stdlib only (crypto/ed25519, encoding/json, net/http).

What became possible:

  • Go developers can interact with any Genesis Mesh NA without a Python environment.

  • The Go SDK is go get-able: go get github.com/GenesisMeshLabs/sdk-go.

  • Admin operations and verify operations are idiomatic Go — typed return values, error values (no panics), context propagation.

  • Proves that canonical JSON and the Ed25519 admin auth protocol can be implemented cleanly in a compiled, statically-typed language.

As of v0.54.0, the following are not yet true:

  • Genesis Mesh does not yet have a C# SDK.

  • No external operator has yet run a sovereign with their own infrastructure account, keys, policy, endpoint, and continuity responsibilities.

Phase M — v0.55.0: .NET SDK (June 2026)

Question this phase answered: Can a .NET 8 / C# developer use Genesis Mesh trust primitives from an idiomatic async/await API published to NuGet, with no Python knowledge required?

What changed:

A standalone .NET SDK was created at sdk-dotnet/ (NuGet package ID genesismesh-sdk-dotnet, targeting net8.0). Published to NuGet.org via GitHub Actions Trusted Publishing.

  • GenesisMeshClient facade with 7 sub-clients: Agreement, Attestation, Boundary, Consensus, DataUsage, Disclosure, Evidence.

  • Auth.cs — CanonicalJson that sorts keys and skips HTML-escaping (byte-for-byte compatible with Python and TypeScript), Ed25519 signing via NSec.Cryptography 25.4.0, BuildAdminHeaders producing the four X-Admin-* headers.

  • Models.cs — 25+ C# records with [JsonPropertyName] attributes mapping PascalCase properties to snake_case JSON keys.

  • Errors.cs — typed exception hierarchy: GenesisMeshException, UnauthorizedException, ValidationException, NotFoundException, RateLimitException, ServerException, NetworkException.

  • 20 xUnit tests passing, using HttpMessageHandler injection for mock HTTP — no running NA required.

  • HttpHandler injection on ClientOptions enables pure unit-test coverage without a live network.

What became possible:

  • .NET developers can add genesismesh-sdk-dotnet from NuGet and interact with any Genesis Mesh NA.

  • All three major non-Python ecosystems (TypeScript/Node, Go, .NET) now have typed, well-tested SDK clients.

  • Proves that the Genesis Mesh Trust API is a genuine cross-language protocol, not a Python-only library.

v0.53.1 — Formal Verification Security Hardening + Dual-Platform Support

What shipped:

  • Formal verification hardening suite (F-01 through F-22): Complete security fixes from the formal verification process covering command allowlist enforcement, signature verification on all paths, token binding to decisions, certificate revocation and renewal, consensus integrity, permission scoping, OS-level sandboxing, audit log chain signing, and fail-closed semantics on unrecognized policies. All fixes verified against 120+ test scenarios and clean under Go race detector on Linux.

  • Windows platform compatibility: Git Bash text encoding (UTF-8 codec instead of cp1252 locale), subprocess variable handling via stdin to prevent shell-eating of $variable references, POSIX chmod/mode handling (Windows uses ACLs), and platform-aware test assertions. All 1,303 tests pass; 4 POSIX-only tests correctly skip on Windows instead of failing.

  • Internal consistency fixes: Clock hermiticity (now= parameter in verification functions for deterministic testing), version sourcing from pyproject.toml via importlib.metadata, documentation cleanup (removed filesystem paths, fixed mojibake).

What became possible:

  • Genesis Mesh hardened against all formally verified adversarial scenarios is now deployable and testable on both Linux CI and Windows dev machines without test breakage.

  • SDKs (TypeScript, Go, .NET) can run their test suites on developer machines running Windows without platform-specific failures.

As of v0.53.1, the following are not yet true:

  • No external operator has yet run a sovereign with their own infrastructure account, keys, policy, endpoint, and continuity responsibilities.

  • Atlas (the public sovereign explorer) has not yet been built.

v0.56.0 to v0.57.2 - Rust Gateway Release Train

The companion Rust repository, GenesisMeshLabs/gateway, now provides a production-oriented trust-verification gateway while preserving the Python implementation as the Network Authority protocol authority. The gateway ships canonical-JSON and signature interoperability fixtures, single and bounded batch certificate verification, pinned authority keys and fresh signed CRL checks, and an embedded OpenAPI endpoint explorer.

The v0.56.x releases added a reviewed proxy for 59 scoped Network Authority operations across agreement, attestation, boundary, disclosure, consensus, data-usage, evidence, enrollment, discovery, treaty, network, and administration services. Clients receive explicit network and service-group permissions, while administrative calls retain the signed X-Admin-* header contract and browser-side signing keeps operator seeds local.

The gateway also added native federation preflight with independently pinned CRL issuers, an opt-in live mesh view of published trust domains, treaties, and memberships, and portable multi-platform distributions. With gateway v0.56.3 the Python authority maintenance it used to host (CRL refresh and pinned-peer revocation sync) moved beside the reference authority in scripts/authority_ops, and a live canary revocation was rejected by three receiving authorities about 11 seconds after propagation. v0.57.x added durable per-issuer CRL checkpoints, a SQLite audit outbox with acknowledged HTTPS delivery, OIDC subject bindings, native mutual TLS, Redis-backed shared quotas, bounded resource controls, and hardened container and dependency release evidence.

These are configurable deployment controls, not certification claims. The gateway does not hold authority private keys, issue production sovereign credentials, or replace relying services’ session and application authorization decisions. See Rust Trust Gateway for the complete integration surface and links to the Rust repository’s operational guides.

v0.58.0 — Declarative Boundary Policy and Gate Framework

Planned as v0.57.0. The core skipped 0.57 because the Rust gateway had already released v0.57.x on its own; from v0.58.0 every component, including the gateway and the Rust SDK, shares one version, enforced by a release-train gate in CI. See Versioning.

Question this release answered: Can a Network Authority operator add and change authorization rules as signed, versioned, auditable configuration rather than code, while every decision still proves exactly which rules produced it?

Why the previous state was insufficient: since v0.28 the BoundaryEngine ran three built-in gates, and anything else was a Python callable passed to add_gate(). A new rule meant a code release. The rule was not signed or versioned, activation was not audited, and a signed BoundaryDecision recorded gate names but not the rule configuration behind them, so an auditor could not tell which version of which rule had applied.

What changed:

  • BoundaryPolicy (models/boundary_policy.py): a signed, versioned document with a PolicySelector (AND across fields, OR within a field; empty = global) and ordered GateSpecs. Every model uses extra="forbid". Activation state is deliberately not signed, so rollback restores the exact previously signed bytes and each activation change is an audit event.

  • GateRegistry: a frozen, in-process map from versioned gate_type keys (max_value.v1) to trusted implementations, with eight generic built-ins. A gate_type is only ever a dictionary key; nothing in a policy reaches import, eval or I/O. Adding a rule means implementing ConfiguredGateType and registering it.

  • Deterministic resolution: every active policy is verified (signature, stored digest, registry validation) before any selector is matched, because an untrusted policy cannot be trusted to say which requests it does not cover. Applied policies are ordered by (policy_id, version) and gates by order. Constraints only add: any failing enforce gate denies, and observe gates record without denying.

  • Policy-bound decisions: BoundaryDecision.policy_binding carries policy_set_digest = SHA-256([(policy_id, version, policy_digest)…]), the per-gate evaluations and context_digest. It is inside the signed body and its key is omitted from the canonical form when absent, so v0.56 decisions keep byte-identical signatures (pinned by golden-byte tests). verify_boundary_decision(..., expected_policies=…) detects a substituted policy. JustificationProof is unchanged structurally; configured gates use the existing inputs/metadata fields and disclose raw values only when the signed policy sets disclose_input.

  • Network Authority: validate / publish / list / active / history / activate / deactivate / verify routes, a policy-aware /admin/boundary/evaluate route, migration 010 with a partial unique index that makes two active versions unrepresentable, and a boundary_policy_enforcement="required" mode that refuses the legacy /admin/boundary/decide route so it cannot be used to bypass policy.

  • Policy-evaluation failures yield a signed DENY with a stable code (policy_signature_invalid, policy_store_integrity_failed, gate_type_unavailable, ambiguous_resolution, policy_expired, missing_context, gate_error); transport and authentication errors stay HTTP errors.

What became possible: new policy domains can be added without changing the engine, resolver, routes, signing, proofs or audit handling. 136 new tests (1,483 in total including integration) cover every gate type, each fail-closed path, restart persistence and offline verification. This sets the decision format that the cross-language verifiers in v0.61 must check.

v0.58.1 — Attestation-Backed Boundary Evaluation

Question this release answered: Can a request be authorized on the basis of a sovereign’s membership attestation, so that withdrawing the membership withdraws the authorization, provably?

Why the previous state was insufficient: every boundary evaluation needed an AgreementRecord. A vendor admitted to a sovereign already held a signed MembershipAttestation with roles and claims, but authorizing its requests meant creating a parallel agreement, and revoking the attestation had no effect on decisions made under that agreement.

What changed:

  • POST /admin/boundary/evaluate accepts exactly one basis, agreement or attestation_id (400 ambiguous_basis otherwise). For an attestation the NA loads it from its own store, verifies its signature against the NA key, and checks issuer-side status, imported revocation feeds, the validity window and that the requester is the subject. Any failure is a signed DENY with a stable code (attestation_not_found, attestation_invalid, attestation_revoked, attestation_expired, attestation_not_yet_valid, attestation_subject_mismatch).

  • The attestation gates (attestation_status, attestation_validity, capability_check over claims.capabilities, freshness_check) replace the agreement gates and run first; policy resolution is shared unchanged with agreement evaluation.

  • AttestationBinding is signed into the decision alongside the PolicyBinding, and omitted from the canonical form when absent, as is the new ContextRecord.attestation_id, so earlier decisions and context digests stay byte-identical. verify_boundary_decision(..., expected_attestation=…) detects a substituted or altered attestation.

  • Policies gain read-only attestation.subject_id, attestation.roles and attestation.claims.<key> facts and the attestation_claim.v1 gate type. The facts live in a private attribute that request JSON cannot populate and the context digest excludes; only the engine binds them, from a verified attestation, and the signed attestation digest covers them.

  • verify_justification_proof now checks each trace entry against the decision’s gate at the same position (trace_gate_mismatch), so a proof cannot describe gates other than those that produced the decision.

What became possible: membership revocation is now also authorization revocation for every system that evaluates through the NA. 33 new tests (1,543 in total including integration) cover allow and deny paths, local and feed revocation, expiry, tampering, basis validation, required enforcement, offline verification and the CLI.

v0.59.0 — Evidence Store in the Network Authority

Question this release answered: Can the full history of a vendor or a secret, from decision to execution, be shown and verified from the Network Authority alone?

Why the previous state was insufficient: the NA signed decisions but did not keep them, and it never saw what controllers did with them. Execution evidence was a signed chain per decision, stored wherever the controller put it, so an audit depended on the controller’s storage, and nothing linked the creation, rotation and revocation of one secret across decisions.

What changed:

  • An opt-in evidence store keeps every signed decision with its context and justification proof, and accepts signed execution evidence from controllers authenticated by registered executor keys. Invalid evidence is refused with a stable code, and every write and rejection is audited.

  • ExecutionEvidence gains optional resource fields that chain one secret’s records across decisions; they are omitted from the canonical form when absent, so existing records keep their bytes.

  • The store is append-only in the database itself: triggers refuse edits and uncovered deletes, unique indexes protect every chain position, and every entry links to the digest of the one before it. Retention removes only a prefix, behind a signed checkpoint the remaining history verifies from.

  • Search, verified per-secret and per-vendor histories, and an export in the stable, versioned gm.evidence.event model; SIEM-specific formats are left to adapters outside GM core.

What became possible: authorization and its consequences are audited in one place. 26 new tests (1,569 in total including integration) cover every rejection code, chain gaps and forks, append-only enforcement, tamper detection, retention, export verification and the full vendor-to-secret history across an NA restart.

v0.59.1 — TypeScript SDK for Governed Secret Lifecycles

Question this release answered: Can a lifecycle controller written in TypeScript run the whole governed secret flow without hand-written HTTP or cryptography?

Why the previous state was insufficient: the NA side of the secret pilots was complete in v0.59.0, but the TypeScript SDK could not evaluate under an attestation, manage policies, sign execution evidence or verify bindings and exports. Its canonical JSON also differed from Python for non-ASCII text and floats, so some signatures could not be produced or checked in TypeScript.

What changed: the TypeScript SDK wraps attestation-backed evaluation, the policy lifecycle and the evidence store; signs execution evidence on the per-secret chain exactly as the reference does; ports decision and export verification; and adds a governed-action helper and reconciliation. It is tested against vectors produced by the core and against a disposable local NA. No core behaviour changed.

What became possible: the pilot controllers can be written in TypeScript, and an auditor can verify the NA’s export offline in either language.

v0.60.0 — Optional High Availability for the Network Authority

Question this release answered: Can the Network Authority survive losing an instance, with no data loss or duplicates?

Why the previous state was insufficient: the NA ran as one process tree on one host and one SQLite file. Rate limits were per process. The signing key was a local file. Two “exactly once” operations were checked in the application: two concurrent revocations computed the same CRL sequence, and one overwrote the other. Losing the host stopped every boundary decision, revocation and evidence record that depended on it.

What changed:

  • A storage backend with SQLite (the default, unchanged) and PostgreSQL. Every store works on both: migrations are shared, with one per-dialect file, and they apply once across instances under a database lock.

  • The database enforces exactly-once operations: nonces are claimed atomically, each CRL sequence is written once (a losing writer rebuilds and retries), policy versions and activation are unique, and evidence chain positions are unique.

  • Shared rate limits and job leases live in the database.

  • Every NA signature goes through one Signer. The key comes from a file, the environment or an Azure Key Vault secret read with the managed identity. HA mode refuses a key file.

  • /readyz checks that the database is a writable primary at the expected schema, and reports the key fingerprint.

  • na migrate-db copies a SQLite database to PostgreSQL and proves nothing was lost. na verify-db checks policies, CRLs and the evidence chain after any restore.

What became possible: the NA can be deployed for production use with HA. The full suite runs on both backends, a concurrency suite races every exactly-once operation, and an integration test kills one of two instances behind nginx mid-load. Every acknowledged decision, evidence record and revocation survives exactly once.

5. Where to Read More

This document changes as the project changes.