09 - Single-Human Two-Login-Roles Control Review (SUPERTRACK I)

Source: artifact 09 (full read, content_length 1206). Verdict: SAME_HUMAN_CONTROL_VERIFIED.

Verified against required dimensions

• Why control exists: stated plainly - "Distinct PG logins do not prevent one human controlling two roles. Quorum binds login plus verified human identity." Correctly identifies that role-distinctness != human-distinctness (the exact prior-review concern, correction #8).
• Roles covered: any principal participating in quorum/approval; principal_human_binding maps each principal (auth_db_role) to a human_identity.
• How same human cannot fill two quorum slots: UNIQUE(activation_id, human_identity_id) - a human can appear at most once per activation; plus UNIQUE(activation_id, principal_class_id); plus "exact class set and distinct human count equal required count." A second login by the same human is rejected.
• Login/session_user binding: "Every approval records principal, exact session_user, current human ID." Bound to live session, not a claimed name.
• Identity evidence without string-proof: human evidence = immutable, independently read-back IdP assertion (provider_subject_sha256); "display/email/free text diagnostic only." This satisfies the no-arbitrary-string-proof rule (matches FIX4/FIX6 evidence discipline).
• How violation blocks activation: shared/proxy/SET ROLE/inherited login/missing/stale evidence = invalid; same-human second login rejected; binding drift/revoke/expiry invalidates approvals and increments epoch.
• Rollback: emergency role cannot approve - only reviewed fail-closed rollback; rollback appends revoke/supersede, increments epoch, readiness false.
• No hidden CASE: separation pairs are ACTIVE manifest rows evaluated generically - consistent with principal_separation_manifest #08, no embedded policy.

DDL sketch present

human_identity_registry(human_identity_id PK, identity_provider_id, provider_subject_sha256 sha256, identity_evidence_id, active, valid_from, valid_until, revoked_at, UNIQUE(provider, subject hash)); principal_human_binding(principal_id PK, auth_db_role UNIQUE, human_identity_id FK, binding_evidence_id, validity, revoked_at). Columns + uniqueness + immutability stated.

Minor advisory (non-blocking, fold into CP-08)

• These two tables are registry/evidence tables, NOT among the 27 sealed manifest children. State explicitly where they live (schema qt001_cp, owner-only, append/immutable, Directus/PUBLIC no DML) and how their integrity is sealed, so they are not an unsealed authority surface. The doc implies immutability ("Human evidence is immutable") but should make the table-level seal/ownership explicit like the manifests.
• Confirm SET ROLE / inherited-membership detection is enforced at evaluation time (the doc lists it as invalid - ensure the binding check reads pg session state, not a stored claim).

Verdict

SAME_HUMAN_CONTROL_VERIFIED. Rationale, role coverage, two-slot exclusion via UNIQUE(activation_id,human_identity_id), session_user binding, IdP-assertion evidence (free-text diagnostic only), violation->block, and rollback are all present and sound. Advisory only (placement/seal of the two registry tables).