Laboratory invitations, claims and bilateral relationships

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 sends specimens to B; B may independently send to C using the same canonical laboratory organization, login and workspace. Direction belongs to a relationship, not an account role. Match tenant, organization, laboratory and environment; display names never identify a party. An active laboratory workspace and verified tenant-scoped staff are prerequisites, not sufficient order authority.

• A sender administrator requests B; B administrator independently reviews and approves. The same person cannot approve both parties even with memberships in both.
• Each party sees its own restricted contact and attestation record; neither receives the other party’s staff contacts or private agreement references.
• Consumer Health Program-only membership is not laboratory identity. Invitations never create an organization, credential, subscription or clinical privilege.

1. Authenticate in the actual laboratory workspace and select the intended environment.
2. Request the immutable performer with desiredCodes, purpose, effectiveUntil and an idempotencyKey; desired codes are requested scope, not approved orderables.
3. Both sides review the current version and approve independently using relationshipId and expectedVersion.
4. Record each party’s own attestations separately. Agreement references are not evidence of Program, clinical or technical authorization.
5. Re-read canonical status after any mutation; stale expectedVersion refuses rather than overwriting another approval.

The staged design creates a random 96-character hexadecimal token, stores its SHA-256 hash and expires it after 48 hours. A row lock protects a single claim; exact verified email, target organization/workspace and environment are checked. Issuing a link reports delivery=not_sent: there is no email service or real invitation delivery.

• The source handoff link uses /auth#reference-invite=TOKEN, never a query parameter or persistent browser storage. TOKEN is a placeholder, not an executable example.
• Fragment consumption, clearing and reopening through genuine sign-in are not implemented. An invitation link is not a currently working claim UI.
• A new sender can bind only after ordinary signup and the existing six-step laboratory onboarding produce authorized canonical identity. New performer target resolution remains blocked; never guess a target.
• Acquisition stages invited, claimed, onboarding, relationship_requested, converted and revoked are separate from relationship approval. Recording onboarding does not complete any of the six steps.

• Revocation or suspension blocks new source eligibility immediately; refresh before menu access and at order time.
• An expired effective window cannot be repaired by a cached connection label.
• An expired, replayed or wrong-target claim is refused; never create a second relationship to hide refusal.
• Historical access is a separate canonical order/Program policy; relationship consent alone never entitles historical results.

requested → review → bilateral_approved
                  ↘ suspended / revoked / ended
Every mutation: scoped actor + expectedVersion + current tuple
Consent ≠ connected transport ≠ Program authorization ≠ clinical release

P1 has 29 disposable PostgreSQL/PostgREST cases, including single claim, scope and direct-table denials. Locally signed test tokens are not genuine hosted Auth. Relationship services remain disabled; no installed relationship authority or usable invitation journey is claimed.