How to accept a requirement set

Use this guide when a sop_changed notification tells you a new SOP version is effective and its requirements await acceptance. You start with an SOP version whose requirement set is proposed; you end with the set accepted and signed, so checks can use it, and with a re-check batch queued for the open checks and drafts bound to the superseded version. Accepting needs review.sops.approve and a fresh re-authentication; reading needs review.sops.read.

Acceptance is a decision signature (the dialog says “Decision signature (non-GxP pilot)”), with the meaning approved derived by the server from the route. Until a set is accepted no check can use it: agent-proposed requirements never drive findings unreviewed.

Prerequisites

A connector SOP with a new effective version whose requirements_status is proposed (the worker’s review_extract_requirements run proposes it after the poll sees the version).
The quality_reviewer, program_lead or program_owner persona, and an identity session that can re-authenticate.

Open the change from the notification

The bell (or the e-mail, which carries only the record type, program name, record id and link) opens the system thread: “New effective SOP version: SOP-BA-012 v4.0. 27 requirements proposed; 4 differ from v3.1. 6 open checks and 1 draft protocol are bound to v3.1; 2 entries were modified inside the observation gap and are listed for re-check.” The canvas shows an sop_diff artifact: changed clauses side by side with page and paragraph citations, and a mapping table where codes were re-issued on a major version.

Review the proposed requirements

Each requirement is {code, text, page, paragraph, chunk_id, modality, role, evidence_expectation}. Codes stay stable across minor versions. Click a chunk_id to open the cited passage of the SOP text in the source viewer (customer_internal, program members only). Edit a code or a clause directly in the artifact: the edit creates a new artifact version with origin = human.

Accept the set with a signature

Choose Accept requirement set (needs review.sops.approve). The dialog shows the statement you will confirm, for example “I, Tomas R., approve requirement set for SOP-BA-012 v4.0 (record 3f9c…). Decision signature (non-GxP pilot).” Choose Re-authenticate: the dialog stores its state in sessionStorage, the identity provider asks you to sign in again, and the dialog resumes. Confirm the statement and enter a rationale. The web app calls POST .../review/sop-versions/{version_id}/requirements/decision with RequirementSetDecision {decision: accepted, requirements[], rationale, reauth_token, statement_ack}.

Read the result

The version now shows accepted with requirements_hash, requirements_accepted_by, requirements_accepted_at and signature_id; the signature page (GET .../signatures/{signature_id}) reads “Signature valid”. The audit row sop_version.requirements_accept carries actor_kind = human, the signature_id and your rationale. A later edit of the requirements is refused with 409 record_signed; a new extraction run proposes a new set instead.

Approve the re-check batch

The impact run (review_sop_impact) lists open checks and drafts bound to the superseded version and targets modified inside the observation gap, and proposes a re-check batch. Approve it from the card: each new check carries supersedes_check_id, the new sop_version_id, requirements_hash and check_logic_version, and runs in the background lane (review_check_batch). Findings arrive under Review › Findings with decision open.

Troubleshooting

Symptom	Cause	Fix
`401 reauth_required`	the re-authentication token lacks `auth_time` or is older than 300 s	re-authenticate again; deployed environments fail closed by design
`409 record_signed` when editing	the set is already accepted and signed	run a new extraction; the accepted set stays as signed
The set cannot be accepted	the version is not `effective`	only effective versions bind; check the lifecycle map on the connection
Statement mismatch	the record changed between the dialog and the submit	reopen the dialog; the statement carries the current record hash