[jeremi]

Summary

Two explanation pages, seated under the "Use from applications" groups and cross-linked from the integration patterns page, the glossary, and the terms specification.

• Authenticate citizens with eSignet over Base Registry Engine (BReg) (explanation/esignet-authentication-over-breg, status: current). Describes registrystack/esignet-relay-authenticator v0.3.0: who owns what between eSignet, BReg, and Mint; the challenge-first login flow with a fresh-consent second lookup; the governed :lookup request shape; what the registry must grant (lookup-only access profile, a required scope only the provider holds, selector profile, separate admin client); claim mapping and the pairwise pseudonymous subject; the fixed error codes; a configuration example; the boundaries (BReg only, Relay deferred, no OTP delivery, enrollment, wallet login, or identity assurance); and the Solmara Lab journey. Seated in the BReg section.
• Automate registry workflows with OpenFn (explanation/openfn-adaptors, status: draft, adaptors at 0.1.0 and unreleased). Describes registrystack/openfn-language-registry-stack: the three adaptors and the @registrystack/client@0.27.0 namespaces underneath; credential shapes (explicit vs profile mode, static vs private_key_jwt); what each adaptor does; the result branches and the no-retry, explicit-idempotency, strong-ETag rules; the synthetic agriculture pilot (three workflows, split principals, breg-webhook-signature-v1 event bridge, deduplicating destination); what the pilot does not establish; and loading the adaptors into another OpenFn. Seated in the Evidence Gateway, Relay, and BReg sections.

Other changes:

• astro.config.mjs: four sidebar entries.
• scripts/information-architecture.test.mjs: the exact slug lists for the Evidence Gateway consumer group and the BReg section now include the new pages.
• explanation/integration-patterns.mdx: one sentence in "Workflow engines" pointing at the OpenFn page.
• reference/glossary.mdx and spec/rs-terms.mdx: the eSignet entries now say which way the integration runs (a separately maintained provider is an ordinary governed client of a registry) instead of saying no service integrates with it, and link the new page.

Evidence

Registry Stack-side claims carry {/* Evidence: ... */} anchors (BReg lookup route and $select/accessProfile, authorize_profile_claims and the access.profile.no_required_scope finding, Mint private_key_jwt and the minted scope claim, the access-token verifier profile both runtimes build, the webhook signature domain, the agricultural-holdings starter, the Node client facade, the Evidence client profile loader, the Relay V2 Evidence-family exclusion and V1 retirement list). Claims about the two external repositories carry TODO[evidence] comments per the spec/rs-arc-g.mdx precedent. The OpenFn page names the upstream commit it was checked against; the eSignet page pins to the v0.3.0 release tag.

Review notes

• Security-sensitive content. Both pages document authentication and authorization integrations (Mint private_key_jwt clients, access-profile grants, pairwise subjects, HMAC event verification). The pages describe behaviour and recommend narrow grants; they change no code. Worth a read by someone who knows the eSignet provider and the OpenFn pilot to confirm the described behaviour matches.
• All five review findings were verified against source and fixed in 087bff4c3, with the reasoning in each thread. Two mattered for security guidance: a dedicated access profile does not isolate the provider without a requiredScopes entry, and neither BReg nor Evidence Gateway accepts a citizen's eSignet ID Token as a registry credential.
• Upstream, not fixed here. The OpenFn Relay adaptor still exposes listEvidenceOfferings against /metadata/evidence-offerings, a route the Relay V2 cutover retired; the page warns against building on it, but the operation belongs in the OpenFn repository's own backlog. Solmara Lab's docs/esignet.md still describes the v0.2.0 JAR, the nia-esignet Mint client, and the Relay esignet-userinfo lookup, so it disagrees with this page until it is rewritten for 0.3.0.

Checks

From docs/site/: npm test (565 pass) and npm run check:production, which is what CI runs: the full source check set (content, evidence anchors, draft links, docset, release manifests, archive lock, cutover, notary surface, markdown, Vale with 0 errors and 0 warnings on the touched pages, OpenAPI, config vocabulary, tutorial dry runs, SVG), the production-shaped build, and the built-output checks (accessibility, llms.txt, SEO, 93,386 internal links).

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-09T15:39:37.400684Z	087bff4	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7ac053f867

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".