One door opens on a date
nobody controls.

Nine decisions written as ADRs, and the schema that follows them, before a feature is built on a guess.

• CamDigiKey lives in NestJS, not Keycloak — the AR-13 correction, as an ADR. It reshapes the container diagram.
• AR-07 PostgreSQL is the system of record; Keycloak holds credentials and sessions.
• AR-04 Pairwise subs persisted per application, never derived.
• AR-08 Link constraints and the re-link policy.
• AR-03 No user holds a government IdP as their sole credential.
• AR-05 Verification never blocks authentication; high-value scopes fail closed.
• Recovery model, tiered by assurance — the one genuinely new design here.
• AR-15 Farms Nexus and CashEW integrate only through the public API and documented claim shapes an outside app would use. No shared database, no privileged path. Both are ours, which is precisely why it has to be a written rule.
• AR-16 Version the API from the first release, with a published deprecation policy. F26 turns bare claim values into objects — a breaking change for every integrator unless versioning lands first.

Done when ADRs are signed, migrations applied, and the adversarial test cases written — even if every one is failing.

Two things at once. Farms Nexus reads a revocable org-attested membership — and the CamDigiKey adapter passes end-to-end against a faithful simulator.

The claim

• F1–F3 Progressive linking with proof, notifications, audit, and the AR-08 constraints present from the first migration.
• F25 + AR-10 Organisations and attestation, bounded scope, evidence rows so revocation cascades. Pulled forward — without it the claim has nothing to release.
• F5 / F26 Provenance on every released attribute.
• Consent as a replayable record, plus the access log.
• F6 Transactional outbox and workers. Recovery for L0–L1. Offline QR via short-lived Ed25519 JWS.

The adapter

• Wrap the published Node client library behind the existing provider seam — do not reimplement the crypto.
• Build a simulator strict enough to fail the way production will, and verify the official library can talk to it. That is your independent check.
• Stand up a Security Server from the published playbooks. Rehearse CSR, import, activate, register — even with approval pending.

Done when A real Farms Nexus account links and keeps its history; its farmer-status field is deleted from the shipping branch, not a demo one; revoking a membership changes what it shows with no redeploy; and a Security Server has been built from scratch twice, by two different people.

An application outside your own company integrates unaided. Farms Nexus proves the mechanism works; an external app is the first evidence that anyone else will accept the dependency — which is the actual thesis.

• F28 Developer portal, sandbox, test users, and the integration contract written down — including the exit commitment from AR-11.
• F7 / F8 / F9 SCIM subset, Shared Signals transmitter, back-channel logout, using RISC identifier-changed alongside CAEP.
• F17 Merge and unmerge with alias resolution, and an event an unprepared app can survive.
• Recovery tier two — L2 users recover through the organisation that attested them.
• Three metrics instrumented: time-to-first-login, share of apps consuming a provenance-carrying attribute, deterministic-to-reviewed ratio.

Done when An app your company does not own reaches first successful login using only the portal, with no call to the team — and its owner has read and accepted the exit terms from AR-11.

Run the Stage 3 pilot on infrastructure that is honestly described, with a restore that has actually been performed.

• Pilot topology — two nodes, managed Postgres with replica, Keycloak HA pair.
• F18 read-only degraded mode · F19 status page and incident comms · F24 restore drills with the achieved RTO recorded.
• F22 Low-connectivity PWA behaviour, tested in a field rather than on a throttled laptop.
• Review-queue tooling and a named person to work it — Khmer name matching will send more here than the tier table implies.

Done when A restore drill has run and the real RTO is written down, whatever it turned out to be; and the review queue is clearing rather than growing.

Credentials arrive and L4 becomes reachable. Because you wrapped the official library rather than writing your own crypto, this is an integration-hardening window — not a three-month project.

• Import the real client ID, HMAC and AES material, and the .p12 keystores. Point at production base URLs.
• Complete Security Server registration: submit CSRs, import and activate certificates, register the subsystem, await approval.
• F14 verify.gov.kh · F15 assurance mapping finalised against what CamDigiKey actually returns.
• F27 Signed and encrypted payloads — mandatory now, because government-derived claims are flowing to third parties.
• Recovery tier three: L4 users re-verify through CamDigiKey. L4 TTLs set from risk, fail-closed enforced.

Size the hardening honestly. Without development credentials your simulator encodes your reading of the documentation — your client and simulator can share the same misreading while every test passes. Wrapping the published library removes most of that risk, but first contact with production is still where you learn what the payloads really look like.

Done when An L4 badge exists that was granted by an authorised adapter and could never have been granted by a mock.