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.

Three things at once. People sign in with the accounts they already have; Farms Nexus reads a revocable org-attested membership; and the CamDigiKey adapter passes end-to-end against a faithful simulator.

The doors

• Telegram, Facebook, phone — the everyday sign-in methods the product goal names. Telegram Login is full OpenID Connect (authorization code with PKCE, RS256, published JWKS) and Facebook is OAuth2, so Keycloak brokers both with configuration alone — unlike CamDigiKey (AR-18).
• AR-17 SMS one-time codes, behind a provider abstraction with two gateways, rate-limited and cost-capped. Section 7.3 rejects SMS outright; amend it to reject what it meant — SMS as a single-vendor sole channel.
• AR-19 · F17 moves to P0. No registration step plus three independent doors means one farmer gets three AttaIDs on day one. Deterministic pre-link on verified phone at first login, a prompt to link when a new provider carries a contact that already exists, and the alias table shipping here — not after the pilot.
• Every social login lands at L0–L1 and says so. None of these providers verify a real-world identity.

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. And the duplicate test passes: one person signing in via Telegram, then Facebook, then a phone code ends up with one AttaID, not three.

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.
• Merge propagation — the downstream event an unprepared app can survive. The merge tooling itself shipped in PH1 (AR-19).
• 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.