Early alpha. Not production-ready. No package publication or broad PHP compatibility claim.

Human conduct · FE-04 · NexusScholar.Screening

Title and abstract Screening

Append-only, snapshot-bound human decisions with independent review, deterministic conflict generations, corrections, adjudication, complete invalidation, and a verified downstream handoff.

Purpose and authority boundary

Screening determines whether locked candidate units proceed based on approved criteria and Protocol authority. The durable FE-04 path is ScreeningConductJournal; it preserves every decision and invalidation and derives the current projection by replay. The earlier ScreeningService remains a useful in-memory contract but is not restart-safe authority by itself.

Human authority: automation or a model may produce ScreeningSuggestion, but it cannot create a final conduct decision, occupy an independent review slot, adjudicate a conflict, or publish a handoff.

Conduct model

VerifiedSnapshotBoundScreeningPolicy
  → conduct header (hash-chain root)
  → review decision(s)
       agreement → outcome
       disagreement → deterministic conflict generation
       correction → supersedes exact current digest
       adjudication → cites conflict + every source decision digest
  → optional complete-source invalidation
  → replayed projection
  → handoff only when every candidate is terminal and conflict-free

Policy permits one or two independent reviews. The same actor cannot fill two slots for one candidate and decision generation. Verdicts are closed to include, exclude, and needs_review. Exclude requires a policy-defined title/abstract reason; other verdicts cannot carry one.

Key types and services

  • ScreeningCriteria binds stage-specific inclusion/exclusion material to the approved Protocol content digest.
  • ScreeningConductPolicy binds the locked candidate set, criteria, Protocol, review count, actor-role assignments, adjudicator roles, reasons, and human approval.
  • ScreeningConductHeader fixes conduct/policy/candidate/criteria/Protocol identity and starts the chain.
  • ScreeningConductDecision represents review, correction, or adjudication with ordinal, prior digest, request identity, human actor, rationale, evidence, and exact source digests.
  • ScreeningConductInvalidation names a verified changed source and the complete current decision set affected by it.
  • ScreeningConductJournal validates append operations and replays current outcomes/conflicts/head/readiness.
  • ScreeningConductHandoff binds terminal included/excluded outcomes, reason codes, supporting decisions, and current journal head.
  • ScreeningConductCanonicalCodec strictly round-trips policy, header, entries, and handoff.

Source: NexusScholar.Screening. Semantics: ADR 0013 and durable conduct in ADR 0031.

Identity, replay, and conflicts

Every record uses canonical-json-record. The policy digest binds source authority; the header digest is the journal root; each entry binds one-based ordinal and previous digest. Request digest deterministically derives decision identity independently of decision time. Persisted bytes must be exactly canonical, and rehydration requires the exact verified Protocol, Deduplication, criteria, and policy authorities.

Conflict identity derives from candidate, criteria, and the ordered current source-decision digests. A correction can therefore create a new conflict generation without rewriting the old one. An adjudication only resolves the exact generation it cites.

Typical developer flow

  1. Create a verified snapshot corpus binding and snapshot-bound conduct policy.
  2. Create the header with an assigned human reviewer.
  3. Preview a decision against the current journal head and actor-role assignment.
  4. Append canonical review entries; use correction or adjudication instead of editing prior records.
  5. When source authority changes, append one invalidation naming every affected current decision.
  6. Create a handoff only when replay reports all required reviews, resolved conflicts, and no needs_review.
  7. Use the outward WorkflowExecution bridge to complete the matching human task with the same actor and exact decision/handoff digest.

Failure and refusal behavior

Screening rejects raw Search input, unlocked/stale candidate sets, wrong Protocol/criteria stage, invalid verdict, missing rationale, unknown reason, automation finalization, unauthorized reviewer/adjudicator, duplicate actor slot, invalid hash chain, stale request, correction of another actor or noncurrent record, adjudication source mismatch, incomplete invalidation, unresolved conflict, insufficient reviews, and premature handoff.

Tests, integration, and nonclaims

ScreeningServiceTests, conduct tests in ScreeningConductFixtureTests, and the conduct fixture pack cover single/dual review, conflicts, same-actor refusal, adjudication, invalidation, and handoff. Gate closure is recorded in FE-04 completion evidence.

AppServices/ResearchWorkspace can commit Screening and its matching Workflow event under one lock and revision. CLI exposes integrity/status only because process entry cannot yet resolve full Protocol/Workflow authority. The module makes no reviewer-assignment UI authority, AI-quality, database, API, cloud, multi-user, production, or broad PHP compatibility claim.