Reference testing architecture & dual-role laboratories

Everything below describes engineering source contracts and isolated test evidence (disposable PostgreSQL, loopback PostgREST, test-signed tokens). Where a behavior is described as "designed", it exists in source and isolated tests only — not as a joined, persisted canonical R1 workflow. This is not an availability, certification or publication announcement.

A laboratory keeps its single existing organization, login and workspace. In one relationship it may be the sending (requesting) laboratory, in another the performing laboratory. Switching between the sending and performing views in the Control Plane changes the view only; it never switches account, tenant or credential.

• Sending (requesting) laboratory: responsible for the requisition it submits, the specimen it collects or forwards, and its own external reference. Who faces the patient or ordering clinician depends on the sender's own business; the R1 design does not assume it.
• Performing laboratory: responsible for its Program, native codes, specimen acceptance, accession, analysis and official clinical release.
• Neither side can read the other's catalog, costs, other partners or unrelated results. Relationship metadata is restricted to each party's own record.

1. Bilateral relationship — each lab approves separately, current version, not suspended/revoked
2. Performer Program (version) + sender-specific API client + Program grant
3. Independently reviewed clinical mapping (full fingerprint, reviewer, effective period)
4. Specimen / collection / geography serviceability + agreed terms version
5. Technical authority: native installation registry + enabled reference gate
6. Canonical order + transmission + reference order link
7. Per-specimen custody evidence
8. Performer clinical release (FINAL, later CORRECTED versions)
9. Sender-scoped result read via existing Partner API scopes

The source order evaluator rechecks each step before a proposed write; the current server path refuses before Core access. Steps 1–2 are modeled in staged SQL; step 3 can only reach draft_hold/paused/revoked because no reviewer authority exists; steps 5–8 have no installed authority. Failure at any step refuses before a write.

• Invite an existing laboratory: a bilateral connection request between two existing organizations. The receiving laboratory's administrator approves or declines; the requester never sees the recipient's staff contacts.
• Invite a new laboratory: a high-entropy token is generated server-side; only its hash is stored. It is single-claim, expires, and is scoped to the intended target. The designed handoff points to standard laboratory registration and the existing six-step onboarding; fragment consumption and genuine signed-in claim UI are deferred. No organization is created automatically.
• Why the six-step onboarding: the performing or sending laboratory must have its own verified identity, catalog and technical authority. An invitation cannot substitute for any of them.
• Relationship request idempotency and mutation version fences are separate from single-use invitation claims: a replayed or expired token is refused, and a second claim never creates a second relationship.
• No email is sent by these source contracts and no live registration of invitees is claimed.

• The performer offers reference work through its existing testing Program at a specific Program version.
• Each sender receives its own separately approved API client and Program grant. Credentials are never shared between senders and never derived from a relationship.
• Commercial and technical attestation are separate approvals.
• One performer installation can serve several senders; result reads and webhooks stay limited to the exact sender Program, using the existing Partner API scopes (21 operations, 9 event types — unchanged).
• Suspending or revoking a relationship blocks new eligibility immediately; the pure historical read contract preserves linked authorized history, while actual canonical API reads independently revalidate current grants (not an operational R1 read).

• Laboratory administrator (each side): requests, approves or declines the relationship.
• Performer Program owner: binds the relationship to a Program version and issues the sender's client/grant through existing Partner API processes.
• Independent licensed clinical reviewer: approves each mapping version (authority not yet established).
• Core operator, security/operations and release owner: install packages, registry and gates.