This is the canonical repository specification for the target Workstream contribution and compensation boundary. It implements ADR 0016 and reconciles the accepted WS-XINT, WS-REV, WS-AUTH, and ADR 0014 contracts.
The files under docs/reference_specs/ are immutable archival inputs. Older
chunk specifications describing guide-bound payment fields are historical,
not the current implementation or compensation authority. Migration
0023_remove_task_payment_policy removes the obsolete guide-keyed policy table,
TASK payment fields, and Submission payment stamp after refusing retained facts
or immutable receipts that still use them. The
migration
implements that delivered removal; CON-05A/05B and CP09 are historical groupings, not
outstanding authority to remove the same storage again. ContributionPolicy
versions and immutable awards remain the compensation boundary. Physical cleanup
does not activate contribution recognition or external fulfillment.
No route, model, action, service identity, or runtime behavior described here exists merely because it appears in this document. Each behavior remains hidden until its owning implementation chunk, AUTH activation, and joint release gates pass.
Normative terms MUST, MUST NOT, SHOULD, and MAY are used in their usual
requirements sense.
Workstream records useful human work independently from whether an external provider later delivers money or project points.
The canonical sequence is:
human Review
-> immutable ContributionRecord
-> immutable CompensationAward when the frozen rule is compensated
-> asynchronous external fulfillment
For accepted submitter work the sequence is:
Authorized Review(accept), or authorized task.post_submit.route under locked false policy
-> REV-owned FinalAcceptance
-> accepted_submission ContributionRecord
-> applicable CompensationAward
The false branch requires the exact current successful routing manifest, locked
human_review_required=false policy and originating AUTH decision event under
the shared acceptance contract.
Required-check success or raw checker output alone cannot create FinalAcceptance.
The delivered ARCH-04E1A route-neutral source row alone also cannot satisfy this
boundary; later publication must add mandatory exact routing/owner-receipt
custody to that same table before CON consumes the REV-owned acceptance fact.
The hidden CON submitter participant is delivered as a source-neutral,
flush-only consumer of a real stored FinalAcceptance and assignment lineage. It
runs only inside the caller-owned root transaction after acquiring the supplied
canonical lifecycle fence. It creates or exactly replays one
accepted_submission ContributionRecord and the complete frozen award set:
zero awards for unpaid work, one for money-only or points-only work, and two for
combined work. Compensated replay checks the original correlation UUID and
award IDs; unpaid replay retains no correlation to compare. This participant
adds no acceptance/source writer, TASK transition, authorization claim, route,
fulfillment root or reviewer contribution.
The boundary MUST preserve four distinct facts:
Reviewrecords the reviewer's decision.FinalAcceptancerecords the stable accept-only lifecycle consequence.ContributionRecordrecognizes who performed canonical work.CompensationAwardrecords what that work earned under a frozen policy.
Delivery, acknowledgement, receipt, and status projection are downstream fulfillment facts. They MUST NOT create or change contribution recognition or award eligibility.
This specification owns the target contracts for:
ContributionPolicy, immutable versions, rules, and award definitions;ProjectCompensationAdapterBinding;- submitter and reviewer policy-version freezing capabilities;
ContributionRecordandCompensationAward;- the mandatory flush-only CON participant used by human decision and shared acceptance;
- generic transactional outbox and shared lifecycle audit participation;
- outbound fulfillment, callbacks, immutable receipts, and rebuildable status;
- contribution, award, and bounded operations reads;
- fulfillment drain observation and joint release dependencies.
It does not own authentication, grants, permission registration, review decisions, FinalAcceptance persistence, task transitions, artifact bytes, provider settlement ledgers, balances, reputation scoring, or adjudication.
All public API paths use /api/v1. No alternate public prefix is introduced.
| Boundary | Owner | Required rule |
|---|---|---|
| Authentication tokens | External Flow Identity Issuer plus AUTH verifier | Workstream verifies external tokens and does not own login, passwords, or primary sessions. |
| Authorization | AUTH | AUTH owns identifiers, mappings, grants, typed contexts, prepared handles, evaluators, evidence, activation custody, and availability. |
| Task assignment | Task subsystem | Task owns TaskAssignment creation, status, and task-claim composition. |
| Human review and acceptance | REV | REV owns queues, leases, Review/finding/resolution state and shared FinalAcceptance persistence. Human decision composition owns its commit; TASK post-result composition owns the false-branch commit. Both reuse the same acceptance sequence through public flush-only participants. |
| Contribution policy and recognition | CON | CON owns policy aggregates, freeze capabilities, ContributionRecord, CompensationAward, and CON reads. |
| Shared outbox mechanics | Shared outbox | The dispatcher owns claim, retry, dead-letter, replay, and finalization, but no feature authority. |
| Artifact bytes and bindings | ART | ART owns artifact persistence and capabilities; it is absent from the core Review-to-Contribution transaction. |
| External fulfillment transport | Typed compensation adapters | Adapters deliver already-created awards and never determine eligibility. |
| Joint release control | REV-12A | REV owns one shared lifecycle controller and mutation fence; CON supplies required hooks and observations. |
Domain participants MUST use the caller's AsyncSession, stage or flush only,
and MUST NOT commit. The request route or service command owns the transaction
and its single commit.
ContributionPolicy is the stable project aggregate that selects the policy
used for new work.
Canonical fields:
id
project_id
name
status: draft | active | retired
current_published_version_id
created_by
created_at
retired_by
retired_at
At most one policy may be active for guide activation in a project. An active policy MUST point to one published version. Missing or invalid policy configuration MUST block guide activation and task readiness; it MUST NOT be interpreted as unpaid work or deferred until assignment/review claim.
Canonical fields:
id
contribution_policy_id
project_id
version_number
status: draft | published | retired
created_by
created_at
published_by
published_at
retired_by
retired_at
Draft content may be edited through the authorized policy service. Published
and retired content is immutable. Publishing a later version affects a work
attempt only when a future guide activation or human needs_revision
preparation deliberately adopts the complete changed context. Existing
Submissions, admissions, ReviewLeases, Reviews, ContributionRecords, and awards
never change; only the continuing Task and TaskAssignment may rebase at that
controlled boundary for the next attempt.
Canonical fields:
id
contribution_policy_version_id
project_id
contribution_type: accepted_submission | completed_review
compensation_mode: unpaid | compensated
Every publishable policy version MUST contain exactly one rule for each
contribution type. An unpaid rule MUST have no award definitions. A
compensated rule MUST have one or two definitions: at most one money and at
most one project_points definition.
Canonical fields:
id
contribution_rule_id
contribution_policy_version_id
project_id
contribution_type
instrument_type: money | project_points
unit_code
quantity
adapter_binding_id
Every policy, award, and fulfilled quantity uses the same fixed-point
NUMERIC(38, 18) value envelope. PostgreSQL persistence retains the unrounded
numeric input and checks at most 20 integer and 18 fractional digits explicitly;
using a NUMERIC(38,18) column typemod directly is forbidden because PostgreSQL
would round excess fractional precision before a check could reject it. API
quantities are canonical decimal strings with
at most 20 integer digits and 18 fractional digits; leading plus signs, binary
floating-point, NaN, infinity, exponent notation, negative values, zero, excess
precision, and values above the database maximum are rejected rather than
rounded. Pydantic, application, and PostgreSQL validation MUST enforce
identical bounds.
For money, unit_code is an uppercase ISO 4217 code enabled for the project.
The immutable ISO code registry is migration-owned from the official current
SIX ISO 4217 List One; application behavior cannot add arbitrary codes. For
project_points, quantity is a whole number and unit_code is the exact
configured project-scoped unit; its
identity is (project_id, unit_code), so equal text in another project is a
different unit. A definition MUST match the rule's project, policy version,
contribution type, and unit. Its binding MUST match the project and instrument.
Published definitions are immutable.
ProjectCompensationUnit is the durable project enablement target used by
award definitions. Its identity is (project_id, instrument_type, unit_code).
Money rows must reference the migration-owned ISO 4217 registry; project-points
rows use the project-scoped configured code. Persistence permits only active
creation and rejects lifecycle mutation until the authorized policy behavior
chunk installs its transition guard. Definitions reference this identity with
a composite foreign key, so regex-shaped but unconfigured units cannot publish.
Canonical fields:
id
project_id
instrument_type: money | project_points
adapter_actor_id
route_key
status: active | suspended
binding_lifecycle_version
created_by
created_at
suspended_by
suspended_at
resumed_by
resumed_at
retired_by
retired_at
At most one binding is active for each project and instrument.
binding_lifecycle_version starts at 1 and increments exactly once per valid
active-to-suspended or suspended-to-active transition. CP02 installs the hidden
transition guards and immutable created/suspended/resumed lifecycle history;
the current transition projection stores database-timestamped suspend or resume
attribution so PostgreSQL can verify the matching immutable event independently.
Retirement remains future and unavailable. route_key is a
1-120 character non-secret ASCII domain routing identifier matching
^[A-Za-z][A-Za-z0-9._:-]{0,119}$; it rejects traversal pairs (..),
whitespace, slashes, URL/query syntax, @, control characters, and Unicode.
Provider endpoints, credentials, tokens,
accounts, balances, and ledger references MUST NOT be stored in this aggregate
or exposed by product reads.
Suspension blocks new freezes and new delivery admission but preserves exact callbacks and replay required for already-issued awards. Retirement MUST fail while an active policy, unfinished frozen work, or an unfulfilled award still depends on the binding.
CON-03C delivers immutable source and award storage. CON-07 adds the hidden source-neutral accepted-submission participant and complete frozen award-set owner. REV-04C composes that participant with hidden FinalAcceptance and TASK accepted/completed effects in one caller-owned transaction for either source. No production recognition route, authorized acceptance operation, reviewer participant or fulfillment consumer is registered. Before activation, originating Review/FinalAcceptance authority, mandatory source receipts and fulfillment-root ordinal custody must be installed; retained pre-authority sources and dependent contribution/award rows must cause refusal unchanged, never receipt backfill or deletion.
Canonical fields:
id
project_id
task_id
submission_id
contribution_type: completed_review | accepted_submission
contributor_id
source_review_id
source_review_lease_id
source_final_acceptance_id
source_task_assignment_id
artifact_hash
contribution_policy_version_id
created_at
The record is immutable. It carries the exact project, task, existing
versioned Submission, actor, frozen policy version, and stabilized artifact
digest lineage.
Reviewer shape:
contribution_type = completed_review
source_review_id = Review.id
source_review_lease_id = ReviewLease.id
source_final_acceptance_id = null
source_task_assignment_id = null
contributor_id = reviewer ActorProfile.id
Submitter shape:
contribution_type = accepted_submission
source_review_id = null
source_review_lease_id = null
source_final_acceptance_id = FinalAcceptance.id
source_task_assignment_id = TaskAssignment.id
contributor_id = submitter ActorProfile.id
PostgreSQL MUST enforce mutually exclusive and complete source shapes, one
completed_review per Review, and one accepted_submission per
FinalAcceptance. Raw checker outcomes create neither contribution type;
authorized false-policy acceptance creates the submitter record through the
same FinalAcceptance source, never a reviewer record.
Canonical fields:
id
project_id
contribution_record_id
contributor_id
contribution_policy_version_id
award_definition_id
adapter_binding_id
instrument_type: money | project_points
unit_code
quantity
created_at
correlation_id
The award is immutable. It copies the instrument, unit, quantity, and binding from the exact published definition evaluated for the contribution. At most one award may exist per contribution and instrument. An explicitly unpaid rule creates no award; absence of an award under that rule is a successful result.
Database constraints and application tests MUST prove the copied unit and fixed-point quantity are byte-for-byte/decimal-equal to the definition; award creation never recalculates, converts, rounds, or accepts binary floating point.
Fulfillment state MUST NOT be stored by mutating the award.
Canonical fields:
id
compensation_award_id
project_id
adapter_binding_id
external_event_id
reported_status: fulfilled | failed
external_reference
fulfilled_quantity
fulfilled_at
failure_code
reported_at
received_at
correlation_id
Receipts are immutable and idempotent by their exact provider/binding event
identity. external_event_id is an opaque 1-128 character ASCII token matching
[A-Za-z0-9._:-]+, unique per adapter binding. external_reference is either
null or a non-secret opaque token with the same length and character bounds; it
is required for fulfilled and null for failed. Neither value is returned by
contributor/product reads or emitted in integration events.
A fulfilled receipt requires the exact award NUMERIC(38, 18) quantity, the
exact binding unit, and a bounded fulfillment time. A failed receipt requires
one closed Workstream code:
ADAPTER_REJECTED, DESTINATION_UNAVAILABLE, PROVIDER_UNAVAILABLE,
PROVIDER_TIMEOUT, or UNKNOWN_PROVIDER_FAILURE; unknown provider values map
to the last code before persistence. Failed receipts have null quantity,
fulfillment time, and external reference. One award has at most one fulfilled
receipt. A conflicting replay fails closed.
Raw provider secrets, authentication tokens, unbounded callback bodies,
free-form messages/codes, headers, signatures, endpoints, credentials, URLs,
markup, provider metadata, PII, balances, ledgers, and settlement data MUST NOT
be persisted, logged, emitted, exported,
or returned. This prohibition does not include the bounded non-secret opaque
external_event_id and external_reference identifiers defined above; those
may be stored only in their canonical receipt/status fields and remain excluded
from product reads and integration events. Only closed canonical facts, those
bounded identifiers, and platform-generated digests derived exclusively from
approved stored receipt fields may cross into receipt, audit, outbox, or
diagnostic records. Digests derived from provider bodies, tokens, signatures,
URLs, PII, balances, ledgers, settlement data, or any other forbidden input are
themselves forbidden and MUST be rejected before persistence.
Canonical fields:
compensation_award_id
delivery_status: pending_delivery | acknowledged_by_adapter
fulfillment_status: pending | failed | fulfilled
latest_receipt_id
external_reference
last_failure_code
delivery_timestamps
fulfillment_timestamps
updated_at
This projection is mutable and rebuildable from immutable awards, delivery history, and receipts. It is not eligibility or settlement truth.
The REV shared acceptance contract owns the single FinalAcceptance schema, exclusive human/checker-policy source shapes, same-chain constraints, actor/authority provenance, currentness and transaction sequence. Both triggers use the same CON submitter operation; no new contribution type, synthetic Review or automatic reviewer award is added. REV-04C delivers the hidden mechanical transaction participant. The authority, currentness, audit/outbox and activation behavior is still planned runtime behavior, not enabled false-policy activation.
CON MUST create accepted_submission only from the supplied locked
FinalAcceptance and exact TaskAssignment. It MUST NOT infer submitter acceptance
by reading Review.decision.
CON validates the acceptance's constrained source and originating AUTH event
against its supplied locked facts, including the exact assignment/Submission
ContributionPolicyVersion and stabilized artifact hash. It evaluates only the
submitter rule for that operation. False-policy acceptance has no reviewer
operation even though the policy contains both actor rules.
Fresh ContributionPolicy and compensation-adapter mutations retain AUTH's AuthorityControl, caller profile/link and scoped Finance grant locks before acquiring product-owner resources. The early scope step issues no mutation handle or audit evidence. Exact resource-bound PREP preparation and consumption remain mandatory after locked policy/binding facts are available. Completed operation replay uses current read authority and does not reacquire a fresh mutation scope. Binding suspension retains its existing eligibility semantics; it does not require an active project merely to stop new binding use.
During authorized Project Guide activation, PROJECTS calls the narrow CON validation participant. CP06 implements this internal caller-transaction dependency; CP07 delivers guide binding, and AUTH-12H supplies explicit live exact-project manager authority. Activation takes the authority-control and principal/grant locks before these product locks. AUTH-18 exposes public manager activation using published selector identities, without granting Finance privileges. It first obtains the PROJECTS project fence, then the CON project-scope fence, and locks the explicitly selected active ContributionPolicy, its current published version, both rules, referenced definitions, and bindings. The requested version must exactly equal the aggregate’s current published selector; missing or stale IDs never select a replacement. Locked graph and unit reads refresh any values preloaded by the caller. It returns immutable identity and graph facts that PROJECTS will bind as:
ProjectGuide.contribution_policy_version_id
TASK readiness inherits that identifier before the task becomes claimable and stores it as:
WorkstreamTask.locked_contribution_policy_version_id
Task claim performs no policy lookup and copies the task lock to:
TaskAssignment.submitter_contribution_policy_version_id
Submission creation copies that exact attempt value to:
Submission.contribution_policy_version_id
The CON participant flushes only and never commits. PROJECTS owns activation; TASK owns readiness, claim composition, and status effects.
After a human needs_revision, task-owned preparation locks the complete
current next-attempt context. If policy changed, it validates the newly active
guide-bound version through CON and atomically rebases the continuing Task and
TaskAssignment for the next submission attempt, recording exact prior/next
lineage. Missing, incomplete, crossed-project, ambiguous, or binding-ineligible
context blocks the whole preparation. Publication alone never performs an
update. CP06’s distinct revision-adoption purpose checks only the supplied
version and current resource eligibility, allowing immutable published or
retired versions without requiring current-selector equality. It does not
verify a complete guide, authorize a revision, or write attempt lineage. The
future TASK/PROJECTS composition must derive those IDs from its locked complete
guide context and cannot use revision-purpose facts to activate a new guide.
An unchanged attempt makes no CON reselection call.
During authorized review claim, REV locks its queue, canonical admission,
Task, TaskAssignment, Submission, and ReviewLease facts. It verifies the
Submission's immutable attempt lineage and copies
Submission.contribution_policy_version_id to:
ReviewLease.reviewer_contribution_policy_version_id
Review claim performs no CON lookup or current-policy selection.
REV owns ReviewLease schema, claim composition, and status effects. CON owns policy validation at guide activation and the controlled human-revision rebase, not ordinary review-claim selection.
- Published or retired frozen versions remain valid for already-started work.
- Later publication MUST NOT alter an existing assignment, lease, ContributionRecord, or CompensationAward.
- Suspension races MUST be resolved with explicit locks and both-order tests.
- Missing, draft, ambiguous, crossed-project, or incomplete policy state blocks guide activation/task readiness or the controlled human-revision rebase.
- Human revision preparation MUST rebase changed award eligibility with every changed applicable context component on the continuing Task/TaskAssignment for the next attempt. The completed Review and reviewer contribution keep the prior ReviewLease version; the next Submission and ReviewLease use the rebased version.
- Accept and reject never rebase. They evaluate the exact assignment and lease versions frozen for the current attempt.
The target decision boundary has two ordered, operation-specific CON methods in the initiating command's caller-owned session. CON-07 delivers the source-neutral submitter port, and REV-04C invokes it from the hidden source-neutral acceptance participant; the reviewer participant remains future human-lifecycle work. Human decision composition will use the reviewer method. Before either trigger uses the delivered participant, its same input/schema must evolve to require the verified AUTH event without an optional/default path, and the complete authorized shared acceptance operation must add shared audit/outbox staging. A combined request carrying nullable FinalAcceptance or both actors' source and policy facts is prohibited.
Human decision order (false routing omits this reviewer operation):
AUTH locks and revalidates exact reviewer authority
-> AUTH prepares review.decision for this session/action/actor/request
-> REV locks idempotency, release fence, queue, lease, task, assignment,
Submission, predecessor Review, findings, and resolutions
-> REV recomposes final typed resource facts
-> AUTH consumes the handle, evaluates once, and stages decision evidence
-> REV appends immutable Review, findings, and resolutions
-> REV consumes ReviewLease and closes ReviewQueueEntry
-> CON reviewer operation creates completed_review and applicable awards
-> REV applies the decision branch
-> REV stages shared audit and outbox rows from invoked CON results
-> request route or service command commits once
The reviewer operation runs for every valid accept, needs_revision, or
reject Review after Review creation and lease/queue closure but before the
decision branch.
Its typed input contains only locked:
- Review and ReviewLease;
- existing versioned Submission, project, and task;
- reviewer actor;
- lease-frozen reviewer ContributionPolicyVersion;
- originating allowed
review.decisionAuthorizationDecision; - request and correlation references;
- server-derived stabilized
Submission.artifact_hash.
It contains no FinalAcceptance, TaskAssignment contribution source, submitter,
or submitter policy. It creates exactly one completed_review, evaluates only
the reviewer rule, stages zero to two awards, returns typed audit/outbox inputs,
and flushes.
Accept (the shared sequence also used by authorized false-policy routing):
REV appends FinalAcceptance
-> Task.status = accepted
-> TaskAssignment.status = completed
-> CON submitter operation
Needs revision:
Task.status = needs_revision
TaskAssignment.status remains active
no FinalAcceptance
no submitter operation
task-owned complete-context preparation keeps/rebases/blocks the next attempt
The Review, reviewer contribution/award, task and assignment effects, initial preparation or blocked outcome, audit/outbox rows, and contributor-visible state commit once or roll back together. The preparation may update the continuing Task and TaskAssignment only for the next submission attempt; it never changes the completed Review, its lease-frozen policy, any prior Submission, ReviewLease, ContributionRecord, or CompensationAward.
Reject:
Task.status = rejected with bounded human reason
same-task TaskAssignment.status = blocked
TaskAssignment block references the reject Review
no FinalAcceptance
no submitter operation
Reject MUST NOT change an actor grant, another task, or another assignment.
closed/review_rejected is not a canonical lifecycle token.
The delivered REV-04C composition invokes the submitter operation only after it has created or exactly replayed FinalAcceptance and staged accepted Task and completed TaskAssignment effects. CON's delivered hidden participant consumes exact stored lineage and neither creates nor authorizes those enclosing facts.
Its delivered typed input contains only immutable scalar IDs for project, task, Submission, FinalAcceptance, TaskAssignment, submitter and the assignment-frozen ContributionPolicyVersion, plus the stabilized artifact hash, caller correlation UUID and expected lifecycle generation. It carries no authorization decision, receipt-shaped value or caller-selected contribution/award ID. Before production consumption, the enclosing REV input must require the exact AUTH decision-event receipt with no optional/default path; the complete shared operation owns authority and request idempotency.
It contains no direct Review or ReviewLease contribution-source fields. It
creates or exactly replays one accepted_submission, evaluates only the frozen
submitter rule, stages the complete zero-to-two award set, returns immutable
contribution/award facts, and flushes. Paid replay checks correlation equality;
unpaid replay has no stored award correlation to compare.
CON MUST NOT commit, call ART, perform provider I/O, or provide a no-op production participant. Any failure in either CON operation or later shared audit or outbox staging rolls back Review, FinalAcceptance when applicable, task and assignment effects, contributions, awards, authorization evidence, audit, and outbox rows.
Canonical Review creation and false-policy acceptance MUST NOT be enabled before their mandatory participants and shared staging behavior are installed. On false, the same rollback guarantee covers TASK routing and acceptance with no Review or reviewer operation; external delivery remains after commit.
The core transaction makes zero ART capability calls. The shared acceptance operation (or human reviewer operation) supplies the exact server-derived verified Submission artifact digest from the initiating locked context; CON copies it to the ContributionRecord without loading bytes, rehashing, verifying, binding, or calling a provider.
Submission.package_hash MUST NOT be used as that digest. Storage validates
Submission.artifact_binding_id = ArtifactBinding.id, Submission.artifact_content_id
= ArtifactContent.id, ArtifactBinding.content_id = ArtifactContent.id and the
record hash = ArtifactContent.sha256; reviewer records also equal Review.artifact_hash.
No new Submission hash alias or artifact byte read is needed.
An optional contribution-evidence document is deferred. If separately approved, it is an asynchronous projection with independent status and failure semantics. It requires fresh ART and AUTH contracts and MUST NOT gate Review, ContributionRecord, CompensationAward, product reads, fulfillment, readiness, or release.
AUTH alone owns:
PermissionIdandActionIdcatalogues and stable mappings;ActionOwneractivation custody;- human grants and fixed-service admission;
- action-bearing fixed-service admission and the static service-action matrix;
- typed principal and resource-context contracts;
- prepared mutation handles and evaluator dispatch;
- authorization decisions, evidence, invalidation, and availability.
ACTORS owns and publicly exposes the closed ActorProfile ServiceIdentity
vocabulary. AUTH consumes that vocabulary for controlled provisioning and owns
which identities are action-bearing; a target-only identity does not acquire a
service-action matrix row or execution authority.
CON owns canonical resource loading, product guards, hidden behavior, and feature tests. Neither subsystem imports the other's repositories or mutates the other's state.
Every protected surface follows:
AUTH registers planned action, mapping, typed context, principal path,
and activation custodian
-> CON merges hidden resource composition, guards, and behavior
-> AUTH integrates the exact evaluator and alone activates the action
-> joint release exposes the surface
Registration, provisioning, static membership, behavior, activation, and release are distinct. Planned actions deny in the real kernel. CON MUST NOT construct permissions, query grants, infer roles, change availability, or provide a production allow fallback.
- Task claim requires one active exact-project
submittergrant. - Review claim and decision require one active exact-project
reviewergrant, no-self-review, and lifecycle guards. - Self reads require exact actor ownership.
- Administrative reads and mutations require the exact action-specific AdminRoleGrant selected by AUTH.
No unrelated project or administrative grant substitutes. Adjudicator grants and adjudication are excluded from v0.1, with no action, policy, queue, state, branch, or readiness dependency in this boundary.
FinalAcceptance creation has no ActionId. Derived ContributionRecord and
CompensationAward inserts inside review.decision add no
contribution.materialize or compensation.award.materialize action.
For mutations, AUTH first locks and revalidates current human actor/link/exact
grant rows or fixed-service actor/link rows. AUTH returns one opaque,
non-serializable, single-use PreparedAuthorizationHandle bound to:
- caller session;
- ActionId;
- actor-reference kind and reference;
- idempotency key;
- canonical request digest.
The owning feature then locks product rows and recomposes final typed facts. AUTH consumes the handle, evaluates exactly once, and stages evidence. Reused, serialized, caller-constructed, cross-session/action/actor/request, binding-mismatched, or authority-lost handles fail before product mutation. A failed substitution attempt does not consume an otherwise valid handle.
Reads use request-scoped authorization plus canonical pre-filtered loaders and concealment. No authorization or grant cache survives the request.
An action-bearing fixed service uses this admission path:
verified service token
-> active ActorIdentityLink
-> active service ActorProfile
-> immutable closed ServiceIdentity
-> exact static service-action matrix row
-> AUTH-09E typed service context
-> canonical feature resource facts
-> authorization decision
There is no database service grant or persisted service/action membership row. Human grants cannot satisfy service actions and services cannot use human grant candidates. Missing provisioned service profile/link rows deny runtime calls and block release readiness, but MUST NOT prevent application startup or Access Administrator provisioning. Startup MAY fail on closed catalogue, matrix, context, evaluator, or active-behavior parity drift.
A closed target-only service identity is not an action-bearing fixed service.
It may be provisioned as a typed product resource, but it has no static matrix
row, AUTH-09E runtime admission, action, permission, or executable feature
authority. workstream.compensation.adapter is the only current target-only
identity; it is eligible to be referenced by an adapter binding and cannot act
as the Finance Authority caller.
Merged AUTH-09B provides the human-administrator-controlled
POST /api/v1/service-actors provisioning route and activates only
actor.service.provision. Provisioning creates an ActorProfile and exact
ActorIdentityLink for an already-approved closed ServiceIdentity; it creates no
role, grant, database action assignment, runtime admission, or executable
feature authority. Every future action-bearing CON dispatcher, delivery,
callback, reconciliation, or rebuild identity requires its own human-approved
feature manifest followed by AUTH-owned identity/matrix registration,
provisioning, AUTH-09E admission, evaluator integration, and exact action
activation. Target-only identity registration never satisfies that path.
The table contains both registered-unavailable and future proposed mappings.
CP01A registers the four adapter-binding read/create/suspend/resume ActionIds,
and CP01B registers the five ContributionPolicy ActionIds. CP03B activated
the four adapter-binding actions for covered human Finance Authority
through the hidden AUTH factory; it adds no public route, fixed-service
identity, or service-matrix row. At the CP03B stage, the five ContributionPolicy
actions were still unavailable;
CP05 subsequently activated them through hidden Finance Authority composition.
CP01C corrected the binding facts before behavior:
create binds project, server-selected binding identity, instrument_type, adapter
actor, and non-secret route key; suspend/resume additionally bind the exact
positive lifecycle version. A binding is project/instrument scoped, so its
authorization facts do not contain a compensation unit. All other rows remain
proposals, including dependency-aware
adapter-binding retirement. Existing PermissionIds remain stable. Policy ActionIds use the
canonical contribution.policy.* namespace while mapping to the existing
compensation.policy.manage PermissionId. AUTH must approve exact identifiers,
principals, contexts, mappings, custodians, and activation in its own chunks.
CP02 implements the route-unreachable CON behavior behind those four binding actions. Mutations require a caller-owned root transaction, a canonical operation digest, a PostgreSQL transaction advisory fence, exact owner facts, and an opaque prepare/consume/close authorization participant before product mutation. Every create, suspend, or resume appends one immutable lifecycle event atomically. Exact duplicate recovery requires fresh read authorization; changed or unauthorized recovery is concealed. Production composition remains deny-default and the actions remain unavailable through CP03A.
CP03 is split to preserve owner and activation custody. CP03A registers
the closed target-only workstream.compensation.adapter service identity and
installs PROJECTS/ACTORS owner-held eligibility adapters; it grants that target
no action or service-matrix membership, and all four binding actions remain
unavailable after CP03A completes. CP03B then installs the AUTH read/PREP adapter and activates only
the four exact binding actions for an authenticated human Finance Authority
covering the exact project. Neither child adds a public route, provider
behavior, or ContributionPolicy authority.
CP04A owns ContributionPolicy read, create-draft, and complete update-draft behavior. CONTRIBUTIONS owns policy and unit truth; COMPENSATION and PROJECTS expose transaction-held public owner ports. Every mutation uses a caller-owned root transaction, advisory operation fence, opaque prepare/consume/close participant, complete graph replacement, and one immutable recoverable lifecycle event. Default composition remains deny-default. CP05 supplies explicit AUTH composition for all five actions, limited to active human Finance Authority with system or exact-project scope.
CP04B owns publication and terminal retirement. Publication locks and
revalidates the complete server-owned graph, project units, and adapter
bindings, computes canonical digest/binding facts, consumes and closes opaque
authority before product effects, and atomically replaces any prior published
version. Database-owned transition custody binds every affected row and event
to one actor, operation, and timestamp. The owner remains deny-default unless the CP05 AUTH adapter is explicitly supplied. CP05
activates the five policy actions using serialized read authorization and exact
transaction-bound PREP. Committed replay checks current read authority. Migration 0012 admits only
the policy resource token and five exact action/permission pairs in the existing
closed audit constraints; it does not
change the event shape or policy lifecycle. CP07A migration
0022_adapter_binding_audit_resource admits the existing
compensation_adapter_binding resource and the four binding read/create/suspend/resume
actions paired with compensation.adapter_binding.manage. Other audit clauses
remain unchanged, and downgrade refuses retained binding audit evidence.
| ActionId | PermissionId | Principal / target | Protocol | Feature owner |
|---|---|---|---|---|
outbox.dispatch |
active outbox.dispatch |
fixed dispatcher / exact event and phase | T | AUTH-OUTBOX-02 shared authority, phase custody and Celery worker composition complete |
compensation.adapter_binding.read |
compensation.adapter_binding.manage |
covered human Finance Authority / binding | Q | WS-ARCH-001-CP03B (active; CP01A registration custody) |
compensation.adapter_binding.create |
compensation.adapter_binding.manage |
covered human Finance Authority / binding collection | T | WS-ARCH-001-CP03B (active; CP01A registration custody) |
compensation.adapter_binding.suspend |
compensation.adapter_binding.manage |
covered human Finance Authority / active binding | T | WS-ARCH-001-CP03B (active; CP01A registration custody) |
compensation.adapter_binding.resume |
compensation.adapter_binding.manage |
covered human Finance Authority / suspended binding | T | WS-ARCH-001-CP03B (active; CP01A registration custody) |
compensation.adapter_binding.retire |
compensation.adapter_binding.manage |
Finance / dependency-free binding | T | CON-10B |
contribution.policy.read |
compensation.policy.manage |
Finance / policy version | Q | WS-ARCH-001-CP05 (active AUTH; CP04A owner; CP05A public composition; CP01B registration custody) |
contribution.policy.create_draft |
compensation.policy.manage |
Finance / policy collection | T | WS-ARCH-001-CP05 (active AUTH; CP04A owner; CP05A public composition; CP01B registration custody) |
contribution.policy.update_draft |
compensation.policy.manage |
Finance / draft version | T | WS-ARCH-001-CP05 (active AUTH; CP04A owner; CP05A public composition; CP01B registration custody) |
contribution.policy.publish |
compensation.policy.manage |
Finance / complete draft | T | WS-ARCH-001-CP05 (active AUTH; CP04B owner; CP05A public composition; CP01B registration custody) |
contribution.policy.retire |
compensation.policy.manage |
Finance / published version | T | WS-ARCH-001-CP05 (active AUTH; CP04B owner; CP05A public composition; CP01B registration custody) |
compensation.fulfillment.report |
proposed compensation.fulfillment.report |
exact bound service / award and binding | T | CON-08B |
contribution.read_self |
contribution.read_self |
contributor / own record | Q | CON-10A |
contribution.read_project |
contribution.read_project |
eligible AdminRole / project records | Q | CON-10A |
compensation.award.read_self |
contribution.read_self |
beneficiary / own award | Q | CON-10A |
compensation.award.read_project |
compensation.award.read |
D11 role set / project awards | Q | CON-10A |
compensation.delivery.reconcile |
compensation.delivery.reconcile |
D11 role set / delivery request | T | CON-10B |
compensation.status.read |
operations.status.read |
Operator / bounded status | Q | CON-10B |
compensation.reconcile.run |
operations.reconcile.run |
reason-bound Operator / request | T | CON-10B |
contribution.projection.rebuild |
operations.projection.rebuild |
reason-bound Operator / request | T | CON-10B |
audit.read |
audit.read |
D11 role set / bounded CON audit | Q | CON-10B |
audit.export |
audit.export |
D11 role set / bounded export | T | CON-10B |
T means the prepared mutation protocol; Q means request-scoped read
authorization.
These mappings do not authorize protected handler execution. Before delivery, reconciliation, projection rebuild, or callback implementation, the human and AUTH must approve an exact ServiceIdentity/ActionId/static-row design or an explicitly closed dual-principal evaluator. Discovery candidate strings are not canonical catalogue identifiers and MUST NOT be registered by CON.
task.claim currently has a stable PermissionId but no ActionId. CP08 lineage
and ARCH-03B task-owned readiness/inheritance composition must merge before AUTH registers
or activates that future action. review.claim and review.decision remain
planned until complete REV composition and the reviewer participant merge; the
inherited task-policy lineage and CON-07 submitter participant are delivered.
AUTH must transfer the complete
REV action set under its canonical custody contract; CON MUST NOT define a
partial local transfer.
The shared outbox is generic infrastructure:
- CON-02A owns persistence and append/flush in the caller transaction.
- CON-02B supplies hidden claim/invoke/finalize, retained per-generation delivery receipts, bounded safe retry/dead-letter, exact replay, an explicit handler registry and project-scoped drain observations. AUTH-OUTBOX-02 activates exact dispatcher authority and audit bindings. ARCH-03C2 registers exact assignment invalidation with separate feature authority and enforced prefork topology. Manual requeue, cancellation and archival controls need separate authority.
- CON-02C owns the shared lifecycle audit participant.
The dispatcher may claim, invoke, and finalize under outbox.dispatch only.
It MUST NOT inherit contribution, compensation, delivery, reconciliation,
projection, callback, ART, or provider authority from an event type. Feature
handlers observe an already-committed invocation through the typed port,
obtain fresh feature authority and their own transaction fence/idempotency,
stage feature-owned state, and return a typed outcome. They MUST NOT directly
claim or mutate OutboxEvent rows.
The hidden delivery owner commits a claim, then commits its invocation marker, then releases every database session before calling a handler. Finalization opens a fresh transaction. Each phase prepares and consumes exact phase-specific AUTH facts before mutation. PostgreSQL delivery tests use real fixed-service AUTH/PREP. AUTH-OUTBOX-02 supplies the evaluator, audit vocabulary, decision foreign keys and exact matching database guards together with Celery composition. It refuses retained attempts without provable authority instead of inventing or deleting evidence.
A handler receives immutable event facts and canonical JSON payload text. The committed-invocation observation joins event and incomplete invocation custody in one independent nonlocking SQL statement, matching project, event, digest, generation, owner and unexpired lease using the same statement-stable database instant for the predicate and returned observation time. It is only a point-in-time observation: it reserves nothing and supplies no feature authority or commit-time guarantee. Feature effects deduplicate by immutable event identity across generations.
Unknown event type/version registrations remain pending and visible as unsupported. There is no default handler. Registration requires a coroutine function, bound async method or async callable instance; synchronous handlers and factories reject before invocation. Claim expiry before invocation can retry with bounded exponential backoff; an explicit safe handler retry can also create another attempt. An exception, timeout, cancellation or crash after the invocation marker commits has unknown effects and stops in dead-letter on finalization/recovery. This includes a crash before the handler actually starts. The dispatcher neither silently retries unknown effects nor promises unconditional at-least-once handler entry. The deadline is independent of handler cancellation cooperation: a timed-out call may still run physically, but its later result cannot replace the recorded unknown outcome.
The database requires the current event projection and delivery receipt to agree at transaction commit in both mutation directions. Completed receipts cannot be changed, removed or reopened. Cancellation is a generation-zero persistence state; an attempted event has no cancellation outcome in this closed delivery contract. Finalization replay retains every original delivery identity, timestamp and digest even after a newer attempt starts. Concurrent finalizers may reauthorize the stored winner's digest once without another write. Database guards reject expired invoked non-unknown outcomes, future completion, leases beyond one hour and retry delays beyond one day. Migration preserves pending events and refuses attempted events without provable retained custody; it does not invent history.
Drain is one project-scoped SQL snapshot. Pending, claimed and retryable counts are disjoint; invoked overlaps claimed, unsupported overlaps nonterminal states, and unresolved unknown invocation remains visible after dead-letter. Counts must not be summed as readiness. Database failure is an error, never zero work. Lifecycle release still requires the consuming owner's fence and feature obligation evidence. AUTH-OUTBOX-02 supplies shared Celery delivery and recovery tasks. ARCH-03C2 registers the exact assignment-invalidation handler and proves its delivery through real Redis transport and a prefork Celery process. Future feature handlers require separate activation; public dispatch routes remain absent.
REV stages the audit and outbox rows for the Review decision after the reviewer operation and the applicable branch/submitter operation. Those rows share the same transaction and rollback boundary as the Review and contributions.
Outbound delivery follows ADR 0014. A typed compensation capability extends
ExternalServiceAdapter and is constructed only through a typed
ExternalServiceAdapterFactory[TAdapter] with explicit composition-root
registration. Product services and handlers do not import concrete adapters,
use service locators, discover plugins, or retain fallback constructors.
Delivery uses three transaction boundaries:
- authorize, fence, validate claim generation and award/binding facts, persist immutable pre-I/O intent, commit, and release database locks;
- call the provider outside every database transaction and lifecycle fence;
- open a new transaction to persist the bounded result and return the typed handler outcome.
Provider failure cannot roll back Review, ContributionRecord, or CompensationAward. Retry and dead-letter behavior remain outbox mechanics.
The callback requires the exact verified fixed service, profile/link, ServiceIdentity, static action row, AUTH-09E context, active action, matching binding route, project, award, instrument, and idempotency identity. It never falls back to a human role or dynamic grant.
Rate limits bind the service actor and adapter binding, not a shared IP alone. Signature/authentication failure, cross-binding or cross-project substitution, changed replay, impossible quantity, or illegal state transition fails closed. Exact replay is idempotent.
Human operations surfaces create bounded durable requests and read status; they do not execute provider calls or rebuilds inline. Independent fixed services execute reconciliation and projection rebuild under their own exact actions. Cross-executor use is denied. Reconciliation may add findings or repair rebuildable projections, but MUST NOT mutate immutable Review, FinalAcceptance, ContributionRecord, CompensationAward, or receipt truth.
REV-12A owns the only JointLifecycleReleaseControl and
JointLifecycleMutationFence. CON MUST NOT create a second controller, phase,
generation, or availability writer.
REV-12A1 delivers its disabled generation-zero persistence and caller-root
mutation fence. The shared acceptance order
now includes delivered hidden AUTH preparation, CON-07 participation and REV-04C
hidden FinalAcceptance/TASK/CON composition, while
mandatory persisted receipt custody remains required before production
composition or consumption. Actual CON root
storage and ordinal allocation remain required before either trigger creates
fulfillment obligations; neither awards nor generic outbox rows substitute. Later REV-12A drain/operator
work extends this same controller; it is not a prerequisite on live human
review for the false branch.
Every creation, requeue, successor, retry-root, and repair path that can admit a fulfillment obligation MUST:
acquire the shared lifecycle mutation fence
-> validate the current generation and phase
-> allocate an immutable increasing ordinal only for a new canonical root
-> preserve the existing root identity/ordinal for same-root retry or requeue
-> persist the obligation or fail
CON dispatch and callback composition consume the same fence. CON also exposes
a same-session read-only FulfillmentLifecycleDrainObservationPort returning:
- pending, claimed, retryable, and in-flight outbox counts;
- nonterminal delivery and callback obligations;
- the current maximum immutable root ordinal.
REV captures and persists the server-derived cutoff. During
the future authorized draining phase with a persisted cutoff, dispatch and
callback may complete only obligations from
the same generation whose root ordinal is at or below that cutoff. They MUST
NOT create a successor, retry-root, repair, or any new obligation. Post-cutoff
denial occurs before provider I/O.
Provider I/O remains outside the fence. REV imports no CON or outbox repository; all communication is through typed ports.
Contribution and award reads use PostgreSQL canonical truth directly. They do not depend on ART, optional evidence, provider availability, balances, or settlement ledgers. Reads use stable pagination, exact self/project scope, pre-filtering, and concealment. Provider references, credentials, and secret routes are never returned.
CP05A exposes only ContributionPolicy administration, using the existing CP05
Finance authority and caller-owned transaction. Under the project-scoped
/contribution-policies prefix, public routes are GET /current,
GET /{policy_id} (optional exact version_id), POST /drafts,
PUT /{policy_id}/versions/{version_id}, and POST to that version's /publication
and /retirement. Mutations require one UUID Idempotency-Key. Closed bodies
contain only the policy name, complete rule graph, or empty decision object.
Current discovery authorizes one exact aggregate and refreshes its selectors
without product locks; ambiguity or concurrent replacement is concealed. The
operation receipt remains immutable across replay and requires current authority.
This does not expose binding administration, guide activation, awards or fulfillment.
Other CON routes remain hidden from public OpenAPI and runtime use until:
- exact persistence, migrations, and retained tests pass;
- hidden product behavior and canonical resource loaders are merged;
- AUTH has registered and then activated every exact action and principal path;
- required service profiles and links are provisioned;
- shared outbox/audit and complete REV composition are installed;
- CON-11 publishes the exact dependency and handler manifest;
- REV consumes it through the single joint controller and completes the joint live drill.
Missing provisioned service rows keep readiness false but do not block startup or administrative provisioning. Optional evidence and ART are not readiness dependencies.
ContributionPolicy is the sole award-eligibility policy. CP06/CP07 and
AUTH-12H deliver validation and authorized guide binding; CP08 and the ARCH
integration deliver locked Task/Assignment/Submission contribution-policy
lineage. These owner paths replace the superseded guide-bound economic policy.
Migration 0023_remove_task_payment_policy completes physical removal of the
unused payment_policies table, TASK's base_amount, currency, payout_type
and payment-version stamp, and Submission's copied payment stamp.
The same cleanup removes mutable repository methods, response/CLI fields and
obsolete fixture behavior. It adds no alias, fallback, dual read/write,
automatic conversion or compatibility response.
The migration locks affected storage and refuses populated removed fields, policy rows, or obsolete keys in immutable TASK receipts before dropping empty storage. Retained evidence is not rewritten or deleted. A database refused by that guard requires an explicit verified inventory and human-owned preservation design; do not infer policy for historical work or fabricate a backfill. Fresh-install parity alone is not preservation proof.
The migration implements this delivered boundary. Earlier CON-05A/05B and CP09 sequencing does not schedule another removal or make public intake a prerequisite for this completed cleanup. The current dependency contract continues to govern acceptance authority, atomic contribution/award effects and later fulfillment activation. Removing unused storage does not activate them.
The following decisions intentionally remain gates rather than inferred answers:
- D11 must select the exact AdminRole candidates for project award detail, delivery recovery, and CON audit read/export before CON-10A/10B or related AUTH registration starts.
- If migration 0023 refuses retained economic facts or receipts, a human-owned preservation design is required before any later migration changes them. The delivered cleanup neither classifies nor deletes retained data.
- AUTH-OUTBOX-01 delivered the exact dispatcher contract; CON-02B delivered hidden delivery mechanics. AUTH-OUTBOX-02 delivers the live evaluator, immutable phase audit custody and Celery delivery/recovery composition. Outbound delivery, reconciliation, projection rebuild and callback execution require their own exact feature-authority contracts before activation.
- Optional contribution evidence remains deferred unless separately approved through fresh ART, AUTH, and CON contracts.
No dependent chunk may treat an unresolved gate as an implicit default.
The core dependency order is a partial order. Persistence and flush-only transaction participants do not wait for generic dispatch:
The shared acceptance order governs the false branch: delivered TASK ARCH-04E1A source schema/detached facts precede the delivered REV-04B acceptance, CON-03C contribution/award storage and CON-07 flush-only submitter participation. REV-12A1 supplies the disabled controller/fence mechanics used through CON's consumer-owned acquisition Protocol; TASK request staging (04E1B-A), hidden AUTH preparation (04E2-A) and REV-04C hidden shared composition are also delivered. Hidden handlers 04E1B-B are next; they must lock TASK before CHECKERS currentness and prove both acceptance/successor-generation race orders. These isolated controls prove mechanical behavior, not acceptance authority. At 04E2-B, make the exact AUTH decision-event receipt mandatory on the same strict input with no optional/default path; add database-enforced FinalAcceptance/TASK/CON complete-set closure, shared audit/outbox and exact activation to prove the first genuine allow with source, FinalAcceptance, TASK effects, CON rows and audit/outbox in one transaction. No standalone allow or fabricated authority fixture is permitted. Actual root ordinal custody and authorized lifecycle transition/drain proof precede live AUTH routing composition. False guide activation follows joint proof. A stable Review FK target is not live ReviewLease/queue/decision behavior. The shared lifecycle/obligation fence is required for either trigger; human runtime and fulfillment endpoints are not prerequisites for accepting without a reviewer. The older interleaving below describes the human branch, not a second acceptance implementation.
The historical CON-numbered sequence below preserves the broader REV/CON interleaving. Its pre-review CON-05A/05B labels are replaced by CP06/CP07, CP08/ARCH-03B/03C and the completed physical cleanup described above. Current shared-dispatch delivery also precedes live task invalidation and ARCH-04E routing; it does not wait for contribution/award persistence or REV decisions.
CON-01 -> CON-02A
CON-03A -> CON-03B -> REV lease/policy-freeze persistence
CON-02C -> REV Review/FinalAcceptance transaction foundation
REV-04B runtime Review/ReviewLease/FinalAcceptance -> CON-03C -> CON-03D
CON-03A -> CON-04A
CON-03B + CON-04A -> CON-04B -> CON-05A -> CON-05B
stable REV revision lineage + CON-03C/03D + CON-05A -> CON-07 -> REV-10
AUTH dispatcher contract -> CON-02B
CON-02B + CON-03D + CON-04A/B + CON-07 -> CON-08A -> CON-08R -> CON-08B
CON-08B -> CON-10A -> CON-10B
CON-02B + CON-10B -> CON-10C
all required hidden behavior and cross-initiative gates -> CON-11
Independent branches may be scheduled separately, but each chunk remains bounded by its reviewed contract. CON-02B is intentionally later because it requires the exact AUTH dispatcher identity/action/admission contract; it is not a prerequisite for CON-02C, CON-03A, or CON-03B.
Cross-initiative interleaving is mandatory:
CP06 exact ContributionPolicy activation validation
-> CP07 hidden PROJECT guide binding -> AUTH-12H exact activation
-> ARCH-03B/03C TASK readiness lock and assignment inheritance
CON-03B ContributionPolicyVersion persistence
-> REV-03 ReviewLease foreign key
CON-02A outbox persistence + CON-02C audit
-> REV-04B runtime Review/ReviewLease/FinalAcceptance
REV-04B runtime Review/ReviewLease/FinalAcceptance + CON-03B
-> CON-03C exact contribution source schema
canonical admission carrying task-locked policy lineage
-> REV-06A claim composition and ReviewLease inheritance
REV-09B stable lineage + CON-03C + CON-07
-> REV-10 first canonical Review-committing transaction
CON-11 exact writer/dispatch/callback/ordinal/drain manifest + REV-12 observations
-> REV-12A shared controller/fence
-> AUTH action-specific activation
-> REV-13 joint release
Every arrow waits for the exact runtime predecessor on then-current trusted
main. Planning documents are not runtime readiness evidence.
Optional CON-09A/09B evidence work is outside this order and requires a separate explicit start after fresh review.
Every implementation chunk MUST bind its changed symbols and tests to the initiative conformance matrix. At minimum, final proof covers:
- immutable policy publication and both-order freeze races;
- explicit unpaid, money, project-points, and combined awards;
- one reviewer contribution for every valid Review;
- accept-only FinalAcceptance and submitter contribution;
- mutually exclusive contribution source shapes and concurrency uniqueness;
- complete rollback across AUTH evidence, Review, FinalAcceptance, task effects, contribution, award, audit, and outbox;
- zero ART calls in the core path;
- planned-action denial and exact human/service authority;
- dispatcher/handler and human/service separation;
- no provider I/O under database locks or lifecycle fence;
- callback replay, callback-before-ack, provider failure, and reconciliation;
- every obligation writer racing cutoff capture in both orders;
- same-generation pre-cutoff completion and post-cutoff pre-I/O denial;
- hidden-to-active route transition under AUTH and joint release control;
- no adjudication action, state, queue, lease, decision, contribution, branch, readiness check, or initiative dependency.
Tests MUST prove required behavior, including authorization, immutable facts, atomicity, retries and real integration boundaries. Coverage percentages are diagnostic only. No implementation chunk may hide failures, skip required proof, or weaken authorization defaults to make CI pass.
This specification does not add:
- login, signup, passwords, Workstream-owned primary sessions, or token roles;
- adjudication, appeal, reversal, replacement acceptance, or mutable awards;
- provider-specific SDKs before their adapter chunk;
- payment accounts, balances, payout batches, invoices, points ledgers, credits, blockchain settlement, or marketplace behavior;
- reputation scoring, aggregation, decay, or automatic grant decisions;
- raw ArtifactStore, storage references, provider credentials, or a second artifact store in CON;
- frontend work before backend contracts and lifecycle guards stabilize;
- a public route before AUTH activation and joint release proof.