The v0.1 persistence layer uses SQLAlchemy 2.x async models, Alembic migrations, and Pydantic schemas.
ActorProfile
ActorIdentityLink
AdminRoleGrant
ProjectRoleGrant
QualificationSnapshot
AuthorityControl
AuthorityIdempotencyRecord
AuthorityInvalidationEvent
Iso4217CurrencyCode
Project
ProjectCompensationAdapterBinding
ProjectCompensationUnit
ProjectGuide
GuideSourceSnapshot
GuideSourceSnapshotItem
GuideSourceArtifactBinding
ProjectSetupRun
GuideSufficiencyReport
SubmissionArtifactPolicy
EffectiveProjectSubmissionArtifactPolicy
PreSubmitCheckerPolicy
PostSubmitCheckerPolicy
ReviewPolicy
RevisionPolicy
ContributionPolicy
ContributionPolicyVersion
ContributionRule
ContributionAwardDefinition
ProjectLesson
Task
Assignment
Submission
EvidenceItem
CheckerRun
CheckerResult
ReadinessCertificate (later optional)
ReviewQueueEntry
ReviewLease
ReviewPacketManifest
Review
ReviewFinding
ReviewEvidenceArtifact
FindingResolution
FinalAcceptance (one accepting Review or authorized TASK routing source)
RevisionContextPreparation
SubmissionFindingResponse
ContributionRecord
CompensationAward
CompensationFulfillmentReceipt
CompensationStatusProjection
ReputationEvent (deferred)
AuditEvent
The canonical target model is introduced by staged WS-AUTH-001 migrations. The current legacy tables remain implementation evidence until their owning cutover chunks merge.
ActorProfile is the single Workstream actor root.
Fields include:
idkind(humanor explicitly provisionedservice)status(active,suspended,deactivated)- permitted display/profile metadata
- database-time creation/update fields
- bounded suspension and reactivation attribution plus immutable terminal deactivation attribution in the v0.1 baseline
Profile status is a guard, not a role or project grant.
Lifecycle invalidation effectiveness is component-scoped. Reactivating a
profile records effective=false -> effective=true for that profile projection
without asserting that its identity link, grants, or fixed-service admission
make the whole actor effective.
The closed service identity workstream.compensation.adapter identifies only
an eligible adapter-binding target. It has no service-action matrix row and no
action authority. ACTORS locks the exact active service profile and its active
service identity link before returning immutable eligibility facts; generic
service kind and every other fixed-service identity are insufficient.
An identity link binds one canonical external issuer and opaque subject to one
ActorProfile. It has active/revoked state plus state-transition-guarded current
revocation and reactivation attribution. The v0.1 baseline enforces
complete attribution and bounded lifecycle reasons. AUTH-09D-B activates exact
link revoke/reactivate mutations. Append-only audit evidence preserves immutable
transition history; the current row carries only the latest state-compatible attribution.
Raw tokens, provider credentials, and full claim payloads are not stored.
The database enforces a unique (issuer, subject) pair across all links and, in
v0.1, at most one active identity link per ActorProfile. Revocation preserves
the immutable link and provenance; it does not free the pair for rebinding.
Link reactivation is component-scoped: it restores only that exact credential
binding, does not reactivate its ActorProfile or restore grants, and cannot
bypass final-effective-Access-Administrator preservation.
Immutable administrative-grant history with role, compatible system/project scope, target profile, issuing grant/actor, reason, active/revoked state, and database time. Roles are Access Administrator, Operator, Project Manager, Finance Authority, and Audit Authority.
Immutable exact-project contributor-grant history with role submitter
or reviewer, target profile, issuing Project Manager grant,
role-specific qualification snapshot, reason, and active/revoked state.
Contributor is the umbrella human product term. A human may hold separate
active submitter and reviewer grants for the same project;
each is revoked independently. Adjudicator grants are outside v0.1.
The review lifecycle defines no adjudication policy, queue, state, decision, or
API; a future separately approved initiative owns any lifecycle definition,
authorization, and release. Celery, checker,
setup, and background workers are internal services,
not human product roles.
An immutable, privacy-bounded record of evidence considered by a covered Project Manager before manual contributor grant creation. It never creates a grant automatically.
The singleton AuthorityControl(id = 1) row serializes one-time bootstrap and
every operation that could remove the final effective Access Administrator.
authority_idempotency_records binds one client key to the exact actor-kind,
opaque actor reference, closed mutation operation, canonical request digest,
and typed committed resource reference. The unique actor-scoped namespace
serializes concurrent retries. New rows begin pending; a deferred PostgreSQL
guard prevents that state from committing, and immutable database triggers
permit only one evidence-backed transition to committed.
The raw request and response body are never stored. Replay returns only an
internal resource type/UUID, optional positive version, and exact successful
status; route-owning code must reload and reauthorize that resource before
external disclosure. New linked audit rows use an actor-bound composite foreign
key while the NOT VALID migration preserves pre-foundation forward references.
Every committed authority mutation has exactly one concrete success event and
one causally linked AuthorityInvalidationRequested event in audit_events.
This foundation persists the request digest and typed replay reference only; no cache, queue,
background job processor, or consumer
acts on invalidation yet.
api_rate_control_counters is a cross-replica fixed-window control for future
first-access and authority-management mutations. Its composite key is the
server-owned control_scope plus a 32-byte HMAC-SHA256 key_digest derived
from the exact verified issuer and opaque subject. It stores database-time
window start/expiry, a saturating BIGINT request count, and database-time
update evidence. It has no actor/profile foreign key or surrogate identifier
and stores no raw issuer, subject, email, role, token, claim, or network data.
One PostgreSQL upsert atomically inserts, increments, saturates, or resets an expired counter using a single statement timestamp. Consumption and bounded expired-row pruning commit in a short independent session before a route may continue. These counters are abuse controls, not identity, grants, product authority, audit events, or a replacement for exact authorization checks.
Existing external ActorIdentity.actor_id UUIDs may become canonical profile
IDs only after exact issuer/subject/subject-kind classification. Typed legacy
profile row IDs never become actor IDs or grants. No email, subject shape,
skill, reputation, profile type, or token role is used to infer authority.
Fields:
idnameslugdescriptionstatuscreated_atupdated_at
Status:
- draft
- active
- paused
- archived
Current guide content is the versioned PDF/DOCX/PPTX original-document manifest and private ArtifactStore objects. Guide metadata writes do not accept inline Markdown; PostgreSQL stores no newly extracted document bodies.
Fields:
idproject_idversioncontribution_policy_version_idstatuscontribution_policy_idactivation_operation_id(the committed guide mutation ledger operation)mutation_generationlast_mutated_by_actor_profile_idlast_mutated_via_identity_link_idlast_mutated_by_admin_role_grant_idlast_mutation_action_idlast_mutation_scope_typelast_mutation_scope_project_idlast_authorization_decision_event_idretained_content_markdown(read-only retained data; excluded from current APIs)task_examples(required ordered JSON list on new guide versions)task_examples_hash(domain-separated canonical commitment to that list)change_summaryapproved_byeffective_atcreated_bycreated_atupdated_atsuperseded_atselected_review_policy_idselected_review_policy_generationselected_review_policy_hashselected_revision_policy_idselected_revision_policy_generationselected_revision_policy_hash
The guide is versioned and human-facing. Uploaded PDF/DOCX/PPTX originals live in private ArtifactStore/S3 objects; PostgreSQL stores their metadata and the ordinary task-example text. The examples are representative inference inputs, not selected assignments, and do not create Workstream Tasks. One project-level policy proposal covers the project task set.
New guide versions require 1–100 examples with nonblank content (at most 65,536
characters), optional title (500 characters), and optional labels (at most
20, each 1–100 characters). The complete canonical UTF-8 JSON list is bounded at
128 KiB. Content, order and optional metadata are preserved. The list and its
hash are immutable; corrections require a new guide version. Retained null
inputs remain stored but cannot start new inference. No document bodies are
extracted into PostgreSQL.
approved_by and effective_at are server-written activation provenance, not
request-body fields and not contributor-facing guide content.
Guide status is exactly draft | active | superseded. New draft rows have null
activation operation, ContributionPolicy binding, approval, effective and
superseded provenance. CP07 activation advances the guide mutation generation
and freezes the exact policy/version binding, consumed authority and original
approval/effective provenance in the committed guide mutation ledger. A successor
supersedes only its explicitly selected predecessor; that predecessor retains its
binding and additionally records superseded_at.
Migration 0023 enforces this custody. Retained unbound active rows remain stored without invented evidence; current active-guide reads require an exact committed activation receipt and exclude those rows. A valid successor may supersede an explicitly selected retained predecessor without backfilling it. AUTH-12H supplies explicit activation authority for a live exact-project Project Manager; composition without an authority adapter remains unavailable. AUTH-18 exposes the existing activation operation and draft-policy activation selectors through public HTTP without adding storage or changing retained receipt semantics.
The internal ProjectLockedPolicyContextPort returns a complete immutable graph
through lock_active_policy_context(project_id) or
lock_locked_policy_context(exact_selectors). Both require a caller root
transaction. The existing frozen selectors resolve the receipt-bound source,
compilation, separate approvals, artifact/effective/pre/post policies,
review/revision selections and ContributionPolicy version. Canonical bodies are
copied into immutable JSON values. Catalogue facts are the recorded ID, version,
schema version and manifest hash; no historical catalogue body is reconstructed.
The reader locks Project, discovers the exact candidate without locking Guide,
then reuses Attempt -> Request -> Guide and the canonical custody order. It
refreshes persisted rows after waiting and retains the caller's locks without
committing. A successor changes active selection but does not redirect frozen
lookup; contribution-policy retirement does not rewrite its saved activation
facts. Inactive Projects and incomplete or inconsistent custody remain
unavailable. CP08 consumes this port in the existing task lifecycle writers.
ARCH-03B1 adds detached ProjectDisplayFacts and GuideDisplayFacts to this
same port result. Nested project/guide identities and guide effective time must
match the validated activation context. Project name/slug/description are current
display metadata, not policy hashes; guide display is from the exact selected
historical guide. TaskService retains no PROJECTS ORM object or private repository.
The same port's read_project_display is existence-only, including draft projects
without guides, and performs no flush, commit or row lock. The separate pre-submit
context consumer remains for its later intake cutover.
Migration 0024 adds WorkstreamTask.locked_contribution_policy_version_id,
TaskAssignment.project_id and submitter_contribution_policy_version_id, and
Submission.contribution_policy_version_id. Draft Tasks begin without a stamp;
initial screening binds the exact guide/project/contribution version. Every
non-draft Task requires it. Claim copies it to an assignment in the same project;
Submission requires its exact assignment and copied version at initial insertion.
Assignment and Submission identities and stamps cannot be rewritten. CP08 permits
only the initial draft-to-screening Task stamp; a future authorized rebase must
replace the Task and Assignment guards together.
Submission's three ART references remain all-null during transaction staging or all-present. The production creation command consumes the exact ART admission and fills all three before its root transaction commits. This is separate from the required initial assignment identity. Hidden exact ART-to-CHECKERS input materialization is delivered by ARCH-04B. ARCH-04B2 adds checker-output attempt custody with exact Submission version and checker-request digest plus immutable verified put/receipt ancestry on each run/slot binding. Binding publication atomically seals the terminal put attempt, verification job and replica identity. Later replica health changes remain possible without rewriting the historical verified ancestry. Its migration refuses retained checker attempts or bindings whose missing evaluation digest or verified ancestry cannot be proven; it does not invent or delete retained data. ARCH-04C implements hidden durable execution/results; ARCH-04D2 supplies exact input, execute and finalize service authority. Migration 0009 validates all terminal non-null material custody against ART's immutable consumed admission, binding, content and verified-replica lineage; current replica health is separate. The superseded CheckerRun payment column is removed; retained nullable Submission payment columns require no invented economic configuration. CP09 owns physical economic-schema removal after its remaining consumers change.
The upgrade refuses before DDL if any non-draft Task, assignment or Submission already exists: earlier attempts lack defensible contribution-policy provenance. It preserves draft Tasks and all guide/policy/activation evidence without backfilling or deleting retained data. Downgrade likewise refuses before dropping stored stamps or restoring incompatible payment constraints.
Draft guides may have no selected review/revision policy while the authorized policy writer is unavailable. Active and superseded guides require both exact identity triples, and PostgreSQL freezes those selections after activation.
Runtime enforcement uses machine-readable policies attached to the guide version. Workstream does not parse guide prose at submission time to decide which artifact checks to run.
Project owners provide open-ended setup material and business terms. Workstream does not force every project owner through one universal intake checklist. Workstream evaluates guide sufficiency, derives machine-readable project policy, and owns the internal controls. A covered Project Manager grant authorizes the guide-policy approval flow before the guide can activate.
Every task records the guide version active at creation or screening time before the task enters READY. Later source adapters must also lock the guide version during normalization before contributors see the task.
When a task is claimed or moved to IN_PROGRESS, its locked guide and policy context does not change silently. A newer upstream guide version can only affect unclaimed work or a controlled revision path when policy allows it and the audit log records the reason.
Material changes require a new guide version or policy version. They include guide source material, submission artifact policy, pre-submit checker generation rules, post-submit checker policy, review policy, revision policy, and their guide-bound contracts. Contribution policy publication is independent of guide versioning. A published version affects work only when a later guide activation binds it or controlled human-revision preparation atomically rebases the continuing Task and TaskAssignment for the next attempt. Ordinary task and review claims only copy the already-locked attempt lineage; prior Submissions, ReviewLeases, Reviews, ContributionRecords, and CompensationAwards never drift.
Fields:
idproject_idguide_idguide_versionmanifest_schema_versionmanifest_jsonbundle_hashcaptured_atcaptured_by
GuideSourceSnapshot is the immutable bundle binding for guide material. It
captures uploaded-document declarations and the owning guide's task-example
commitment. It accepts document/upload items only. Downstream records bind to
source_snapshot_id and a server-derived source_snapshot_hash copied from
GuideSourceSnapshot.bundle_hash.
bundle_hash is:
sha256(canonical_json(manifest_json))
Canonical JSON uses UTF-8, sorted object keys, and no insignificant whitespace.
The guide_source_snapshot.task_examples manifest contains the example hash
and count, the server-owned snapshot id and generation plus each
server-owned item id/order and its non-authoritative source metadata. Caller
hashes, content identifiers, excerpts, provider references, and fetch locators
are excluded. Each guide has one declared document set. Changing a declaration,
document bytes or task examples requires a new guide version, which receives
its own internal snapshot and initial setup.
Fields:
idsource_snapshot_iditem_ordersource_kindsource_labelingestion_adaptermedia_typecreated_at
GuideSourceSnapshotItem records each uploaded document in the guide bundle.
Its current source_kind is document and ingestion_adapter is upload;
source_label is display metadata, never a fetch locator. Exact original bytes
are bound by committed GuideSourceArtifactIngest document custody and
ArtifactContent. The setup agent receives only scoped opaque handles, not S3
keys or credentials. No URL fetching, Markdown body, or extraction continuation
is part of this path. File access and provider allocations retain exact original
identity under the runtime custody contracts below.
A new guide version requires its own sufficiency findings, policy proposals, acknowledgements and approvals before activation. Prior immutable evidence is retained and cannot substitute for the new version's evidence. Tasks already locked to an earlier guide and snapshot retain that policy context unless an explicit audited rebase occurs.
The field and status inventory below includes retained superseded setup
setup diagnostics, not instructions to implement those continuations again.
The unified path uses the compilation/projection/finalization contracts below:
after its finalization receipt exists, the run and its output references are
immutable. Later approval, post-policy projection and correction own separate
operation provenance. New model output requires a new compilation generation,
not reopening a finalized policy_draft_ready row.
Fields:
idproject_idguide_idguide_versionsource_snapshot_idsource_snapshot_hashsetup_generationcelery_task_idcontinuation_verification_job_idcontinuation_started_atstatuscurrent_stepoutput_sufficiency_report_idoutput_submission_artifact_policy_idoutput_post_submit_checker_policy_idpost_submit_derivation_summaryerror_codeerror_summaryerror_artifact_incident_idcreated_bycreated_atupdated_atstarted_atfinished_at
ProjectSetupRun is a non-authoritative orchestration ledger for automatic
project setup. It records that Workstream queued or attempted the guide
sufficiency, submission artifact policy derivation, and post-submit checker
policy derivation continuations for one guide source snapshot. It does not
replace the source snapshot, sufficiency report, submission artifact policy,
effective project policy, pre-submit checker policy, or post-submit checker
policy rows.
setup_generation is a positive, guide-local monotonic identity. It prevents
an earlier setup run from continuing after a newer run exists for the same
draft guide; it is not a user-visible revision number.
Current step values are stable setup diagnostics, not product lifecycle states:
queuedenqueueguide_sufficiencysubmission_artifact_policy_derivationproject_setuppost_submit_checker_policy_enqueuepost_submit_checker_policy_derivationpost_submit_checker_policy_compilation
Statuses:
queueddispatch_pendingenqueue_failedrunning_sufficiency_agentsufficiency_blockedrunning_policy_derivation_agentpolicy_draft_readyrunning_post_submit_derivation_agentpost_submit_setup_blockedpost_submit_policy_compiledsetup_blockedfailed
The run references downstream truth by id/hash. Operators can read the latest run through the project setup API to understand whether setup is still queued, blocked by guide sufficiency, waiting on policy approval, compiling post-submit policy, blocked by unsupported checker requirements, or failed at the Celery queue layer. Retained error summaries and post-submit derivation summaries are bounded and redacted. Operational diagnostics use fixed safe events plus validated request and correlation IDs; they do not retain sensitive messages or bodies. See the observability operator guide for the privacy, access, retention, correlation, and outage contract. The default setup-run API returns the source snapshot id for correlation, but does not return the exact source snapshot hash; exact hashes remain available through source-snapshot and policy records when an authorized workflow needs provenance inspection.
Fields:
idproject_idguide_idsource_snapshot_idsource_item_idproject_setup_run_idsetup_generationcontent_idverified_replica_idlogical_rolesupersedes_binding_idcreated_by_servicecreated_at
GuideSourceArtifactBinding is retained read-only evidence from the removed
guide verification flow. Current guide setup uses committed original-document
metadata and attempt-scoped document access records; it creates no new binding
or extraction records. The retained binding links a source item and setup
generation to its recorded ArtifactContent and replica. Composite foreign keys preserve the exact
project, guide, snapshot, item, setup-run, generation, content, and replica
lineage. Retained supersedes_binding_id references remain intact. Their presence
does not authorize any current reader or writer.
Fields:
idproject_idguide_idguide_versionsource_snapshot_idsource_snapshot_hashstatusfindingssummaryagent_nameagent_versionproject_setup_run_idsetup_generationagent_material_sha256agent_material_byte_countcreated_bycreated_atwarnings_acknowledged_by_rolewarnings_acknowledged_by_actorwarnings_acknowledged_atacknowledgement_note
Status:
passedblockedpassed_with_warnings
Finding severity:
blocking_gapwarninginfo
The unified compiler assesses sufficiency once for the immutable guide material.
Blocking gaps stop at findings; sufficient guides stop at draft policy review.
The deterministic sufficiency projector creates the report from the persisted
ProjectGuideCompilation, with server-owned agent identity. Provider-returned
names and versions never establish provenance. The exact source snapshot hash,
setup generation, canonical material hash/byte count, document access evidence
and compilation identity bind the current original-document source evidence.
The compilation input additionally binds the exact task-example list through
its canonical input hash; source snapshots commit its hash and count.
Manual reports use their separately authorized API and persist null agent name and version. They do not execute inference or supply compilation provenance. POL-05A supplies hidden setup-wide correction and canonical human request admission. AUTH-12F4 and POL-05B remain responsible for public authorization and manual dispatch. The removed run-sufficiency route has no compatibility path.
The live Celery path consumes the sufficiency projector under fresh fixed-service
authority. Its immutable ProjectGuideComponentProjectionOperation binds the
attempt, compilation, generation, component/result hashes and authorization.
Projection itself leaves setup unchanged; the separate finalizer atomically
records permitted outputs and seals the generation.
Fields:
idreport_iditem_ordersource_item_idbinding_idcontent_idextraction_usage_idextraction_attempt_idextracted_content_idproject_setup_run_idsetup_generationcanonical_output_sha256
This table is retained read-only evidence; current compilation writes no rows here. Each retained row records which exact ART binding and extraction lineage supplied one ordered source item to a sufficiency report. Composite foreign keys prevent mixing source items, content, extraction attempts, setup runs, or generations. A report cannot consume the same extraction usage twice or assign two items the same order.
Fields:
idproject_idguide_idguide_versionsource_snapshot_idsource_snapshot_hashpolicy_versionlifecycle_statuspolicy_bodypolicy_hashderivation_sourcesource_material_refsderivation_agent_namederivation_agent_versioncreated_bycreated_atupdated_atapproved_by_admin_role_grant_idapproved_by_actor_profile_idapproved_atsupersedes_policy_idsuperseded_atchange_summary
Example:
{
"policy_version": "v1",
"policy_body": {
"required_artifacts": [
{
"key": "answer",
"path": "outputs/final-answer.md",
"hash_required": true,
"required": true
}
],
"required_evidence": [
{
"key": "oracle_test_log",
"label": "Oracle test log",
"hash_required": true,
"required": true
}
],
"forbidden_artifacts": [
{
"pattern": "*.tmp",
"reason": "Temporary files are not reviewable."
}
],
"attestation_terms": ["project_specific_originality"],
"manifest_required": true,
"artifact_hash_required": true,
"artifact_hash_algorithm": "sha256",
"maximum_file_size_bytes": 52428800,
"maximum_package_size_bytes": 104857600,
"packaging": {
"package_required": true,
"allowed_package_formats": ["zip"]
}
},
"policy_hash": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"derivation_source": "unified_compilation",
"derivation_agent_name": "ProjectGuideCompilationProjection",
"derivation_agent_version": "v1",
"source_material_refs": ["artifact-content:00000000-0000-0000-0000-000000000030#extraction-usage:00000000-0000-0000-0000-000000000040"],
"lifecycle_status": "draft",
"approved_by_admin_role_grant_id": null,
"approved_by_actor_profile_id": null,
"approved_at": null
}The live unified compiler proposes this policy together with sufficiency and separate pre-submission/post-submission policy components. ART readiness starts one Celery compilation; sufficient guides stop at draft review and blocked guides stop at findings. The deterministic artifact-policy projector consumes the persisted component only after its exact sufficiency projection exists. Its immutable operation binds inputs, output digest, prior report, generation and authorization evidence. Finalization records the exact permitted outputs.
derivation_source, agent identity and generated policy version are server-owned
provenance. Clients cannot supply them or use the reserved agent- version
prefix. Manual drafts retain their own authorized creation/update provenance.
The manual approval route is removed. POL-05A reviews the complete unified
proposal and atomically approves effective/pre-submit policy with immutable
custody, or records a correction successor. Public authorization and dispatch
remain AUTH-12F4 → POL-05B. Projection itself creates no approved policy.
This immutable internal receipt records one guide_sufficiency or
submission_artifact_policy projection per setup generation. It is the replay
and provenance boundary between a persisted unified compilation and the
canonical product row; it is not another report or policy source of truth.
Changed lineage, output content, authority evidence, or replay facts fail
closed. Database guards prevent updates, deletes, or truncation of projection
custody and of the protected agent-derived business content.
Project policy can add stricter requirements, but it cannot weaken Workstream's default submission artifact policy.
artifact_hash_algorithm is platform-locked to sha256 for v0.1. Project
policy cannot change it, and trusted task runtime parameters cannot override it.
source_snapshot_hash is server-derived from the referenced snapshot bundle
hash.
Policy content, hashes, approval provenance, and source binding are immutable after approval:
draft -> mutable
approved -> immutable
superseded -> immutable
Changing an approved policy creates a new policy revision with
supersedes_policy_id. During that locked replacement transaction, Workstream
may update only the prior row's lifecycle closeout metadata
(lifecycle_status = superseded, superseded_at) so operators can see the
current lineage directly. Policy body, policy hash, source snapshot binding,
approval actor, approval role, and approval timestamp are not edited in place.
The hidden finalizer records one immutable receipt per setup generation, compilation, operation, and authorization decision. Composite custody binds the accepted compilation, attempt and request, exact sufficiency projection/report, and the artifact-policy projection/draft when required. Canonical fact and authority digests include the complete lineage and explicit nullable policy triple.
In one caller-owned root transaction, the receipt and setup transition commit
or roll back with staged authorization evidence. guide_blocked closes as
sufficiency_blocked; ready and warning results close as policy_draft_ready.
Only status, diagnostic step, the two output pointers, and completion time
change; updated_at is preserved. PostgreSQL assigns receipt creation and setup
completion the same transaction timestamp and prevents receipt or finalized
setup rewrites. Legacy-only setup generations retain their existing lifecycle.
Exact replay uses the stored pre-finalization source digest and verifies the closed setup outputs and timestamp before returning the stored receipt. It creates no new evidence or projection. AUTH-12B2 supplies the explicit concrete finalization adapter with current service and exact historical authority checks. The default port remains unavailable; HTTP and Celery composition belongs to POL-04B. Finalization grants no approval, activation, post-submit, or task-readiness behavior. Later live post-submit integration requires separately reviewed custody because this finalized setup row is immutable.
Generated server-side from:
WorkstreamDefaultSubmissionArtifactPolicy
+ SubmissionArtifactPolicy
Fields:
idproject_idguide_idguide_versionsource_snapshot_idsource_snapshot_hashsubmission_artifact_policy_idsubmission_artifact_policy_hashlifecycle_statusmerge_algorithm_versioneffective_policyeffective_policy_hashcreated_bycreated_atsupersedes_effective_policy_idsuperseded_at
This policy is deterministic. It preserves Workstream defaults first and adds project-approved requirements. Duplicate project rule keys are rejected before merge. Default and project rules merge by canonical key, and any project rule that conflicts with Workstream defaults is a project setup defect.
The merge contract is executable per field:
| Field | Merge rule |
|---|---|
required_artifacts |
union by canonical artifact key |
required_evidence |
union by canonical evidence key |
forbidden_artifacts |
union |
attestation_terms |
union |
manifest_required |
logical OR |
artifact_hash_required |
logical OR |
allowed_storage_schemes |
intersection |
artifact_hash_algorithm |
platform-locked sha256; project policy cannot change it and task runtime parameters cannot override it |
maximum_file_size_bytes |
minimum non-null limit |
maximum_package_size_bytes |
minimum non-null total expanded ZIP byte limit |
maximum_archive_size_bytes |
minimum non-null byte limit for the entire compressed ZIP, including archive metadata |
maximum_archive_entries |
minimum non-null normalized outer-ZIP tree entry limit, including implied parent directories |
packaging |
restrictive merge; conflicts block activation |
A required artifact or evidence rule matching a forbidden artifact rule blocks project setup as a policy conflict. It is not deferred to contributor submission.
Approved and superseded effective policy content and hashes are immutable.
Recomputing the effective policy after guide/source/policy changes creates a new
row and hash. Supersession is represented by the replacement row's
supersedes_effective_policy_id. During that locked replacement transaction,
Workstream may update only the prior row's lifecycle closeout metadata
(lifecycle_status = superseded, superseded_at).
Fields:
idproject_idguide_idguide_versionsource_snapshot_idsource_snapshot_hasheffective_policy_ideffective_policy_hashlifecycle_statuscompiler_versioncompiled_bundlecompiled_bundle_hashchecker_names(derived index projection)checker_configs(derived index projection)created_bycreated_atsupersedes_pre_submit_checker_policy_idsuperseded_at
Generated server-side from EffectiveProjectSubmissionArtifactPolicy, then
persisted and locked for the project guide version before tasks enter the
contributor pipeline. Every task under the same active project guide version reuses
that guide version's project pre-submit checker bundle. If the guide version
does not cover the task set, activation is blocked and the guide is improved or
the work is split into another project/guide. The task stores
locked_pre_submit_checker_bundle_hash, which equals
PreSubmitCheckerPolicy.compiled_bundle_hash; it does not own a newly derived
policy or newly compiled checker.
ARCH-03B8 adds no storage: its bounded task audit evidence page projects fixed
shared audit fields with exact project/task scope in one SQL statement. Typed
claim/start references bind assignment and authorization decision without raw
payload exposure. ARCH-03C7 exposes the page to exact covered Audit Authority
using existing TASK/AUTH locks and atomic ALLOW evidence. Draft and empty history
need no policy body. Migration 0005 extends only the existing authorization
action/permission constraint for audit.task.evidence.read / audit.read; retained
records and the shared persisted audit namespace are unchanged.
Task context APIs read this already-stamped context. work-context and
submission-requirements return task-visible contributor-safe guide and requirement
projections from the locked rows. ARCH-03B7 makes requirements immutable with
separate contributor and management result types and one historical translator.
Nested rules, storage constraints and typed packaging cannot carry arbitrary
policy fields. ARCH-03C5 exposes separate Contributor and Manager requirements
reads using exact current project authority. TASK and assignment locks precede
AUTH and historical PROJECTS resolution. Contributor visibility requires
ready/unassigned work or an exact own active assignment; Manager access requires
a covering Project Manager grant. No policy row is written by these reads.
ARCH-03B6 provides explicit management,
operational and audit locked-context projections containing exact source,
effective/pre/post-submit policy, review, revision and ContributionPolicy references.
Only management includes the bounded post-submit checker summary. ARCH-03C6 exposes three distinct project-scoped reads with covering
Project Manager, system Operator or covering Audit Authority grants. The old
task-only route and unused owner wrappers are removed; shared historical
resolution remains. Read serialization and ALLOW evidence commit atomically. Contribution-policy provenance comes from the guide-bound
task lock copied to TaskAssignment and stamped on each immutable Submission;
future ReviewLease propagation must copy that Submission stamp.
None of these reads recomputes from the current active guide.
Approval creates a project-scoped PreSubmitCheckerPolicy row with lifecycle
status compiled. The trusted compiler writes the immutable compiled_bundle
JSON and compiled_bundle_hash in the same approval path. The compiled bundle
is the canonical checker source of truth. It is stored as a structured snapshot,
not arbitrary executable code. compiled_bundle_hash binds the exact compiled
logic to effective_policy_hash. checker_names and checker_configs are
derived index projections only; they must be regenerated from compiled_bundle
and must not disagree with it.
The compiler must prove semantic coverage: every enforceable
EffectiveProjectSubmissionArtifactPolicy rule must produce deterministic
checker logic. It rejects checker specifications that omit a required artifact,
skip an evidence rule, weaken severity, omit a platform default, or produce a
bundle whose rules are not traceable back to the effective project policy.
For v0.1, task-specific runtime parameters come only from trusted task-contract fields already owned by Workstream, such as task id, expected output, declared artifact labels, or acceptance criteria references. There is no free-form parameter map. Runtime parameters may fill placeholders in the locked checker bundle, but they cannot change required checks, severity, allowed storage, forbidden artifacts, hash algorithm, or platform defaults.
Compiled checker bundles, hashes, and effective-policy bindings are immutable.
Changing policy or compiler output creates a new row with
supersedes_pre_submit_checker_policy_id. During that locked replacement
transaction, Workstream may update only the prior row's lifecycle closeout
metadata (lifecycle_status = superseded, superseded_at).
The generated checker order is deterministic:
- packet shape
- artifact manifest presence
- artifact hash validation
- storage reference safety
- forbidden artifact blocking
- required artifact presence
- evidence requirement presence
- contributor attestation validation
- low-quality artifact warnings
POL-07B removes the standalone JSON precheck and connects the internal checker phase service. Authoritative pre-submit checking already belongs to the preparation request owning the uploaded ZIP and bounded scratch. Broader Submission caller migration remains WS-ARCH-001-02I.
The following structured public feedback is the target intake contract; the
existing hidden route currently returns only pre_submission_checker_failed:
POST /api/v1/tasks/{id}/submission-bundle-preparations
422 DomainError(code="pre_submission_checker_failed", details={status, eligible_to_submit, results})
No independent precheck route remains. A client-owned manifest
cannot reproduce the authoritative result. At the later public cutover,
POST /api/v1/tasks/{id}/submissions will consume the verified ready admission
without receiving scratch paths or rerunning the pre-submit plan. Canonical
admission-backed creation remains hidden until then.
Before that cutover, hidden pre-submit materialization establishes the execution boundary without
exposing a route. The fixed materializer authorizes before any prepared-byte
read or workspace reservation. One callback-scoped sealed tree is checked
against the server commitment and semantic manifest. The locked project-policy phase extends that same
callback to execute the locked project-policy phase and normalize every
platform and project result into one typed envelope. The tree is cleaned before
the transaction-bound evidence service reloads the actor, identity link, task,
assignment, predecessor, guide and locked policy rows and persists one
PreSubmitEvidenceSet with ordered PreSubmitEvidenceResult members. Evidence
identity is deterministic over the complete custody and locked-policy context;
exact replay returns the same durable set without minting another pass
capability, and changed facts fail closed. Only first persistence of a passing
execution produces a process-local, generation- and predecessor-bound
single-use capability for immediate admission continuation; a later attempt
must re-prepare the bundle. The evidence-set ID alone is never that capability.
ART-04C1 consumes that live capability and exact prepared generation inside the
final authorization transaction. One immutable SubmissionBundleDurableIntent
then joins the passing evidence set one-to-one with the generic
ArtifactPutAttempt. The join is the database-recoverable producer fence for
later verification publication; it does not duplicate evidence lineage, store
scratch state, or create a bindable admission. Provisional capacity, the put
attempt, authorization evidence, and this join commit before provider I/O.
Generic observation and recovery continue from the put attempt after process
loss.
ART-04C2 adds one SubmissionBundleAdmission only when the verifier's complete
read produces a matching successful receipt. The row joins the exact durable
intent and evidence to provider-neutral content, the verified replica, the
verification receipt, and exactly one direct-put or observed-confirmed receipt.
It starts in ready. The hidden ART admission-consumption capability may apply
ready -> consumed|stale only inside a caller-owned root transaction after
exact TASK and ART lineage validation. A consumed admission records the exact
Submission identifier and lifecycle version while its generic artifact binding
uses its independent binding-chain version. The capability remains deny-only
and route-unreachable until the later TASK composition and AUTH activation
chunks.
The hidden preparation route keeps scratch and prepared handles process-local,
returns before durable verification finishes, and remains excluded from OpenAPI
and crosses the active artifact.submission_bundle.prepare PREP boundary before durable intent.
Blocking pre-submit failures prevent submission creation, create no submission
row, no submission version, no task transition to submitted, and no
submission-created audit event. ART constructs an audit-ready projection;
publication as a task event named pre_submission_check_failed remains pending.
That event must use bounded identifiers, catalogue identity,
stable codes, counts and categories for project operators. It excludes paths,
filenames, scratch/provider references, raw output, evidence contents,
credentials and free-form checker messages. Pre-submit results never return
review decision values.
The canonical checker_policies row contains project/guide/version and exact
source snapshot, effective-policy and pre-submit-policy IDs/hashes; policy_body
and policy_hash; required/warning checker and blocking-severity sidecars;
lifecycle_status; projection_operation_id, approval_operation_id and
supersession_operation_id; approval/supersession timestamps; predecessor
supersedes_policy_id; and creation metadata.
policy_body is the sole execution body. Its hash is
sha256(canonical_json(policy_body)); sidecars must match it. Lifecycle is
compiled, approved or superseded. POL-06A derives a compiled policy only
from a finalized unified result with the current approved artifact/effective/
pre-submit chain. Separate exact-target manager approval records its receipt.
Both compiled and approved policies may be corrected while their setup is current.
The append-only project_post_policy_operations family records derive, approve
and correction receipts with exact actor, identity link, grant or fixed service,
authorization decision, finalization, source/result, upstream approval, catalogue
and policy commitments. Active-guide readers require that custody. Historical
role-string approval/supersession columns remain inert retained data; they do not
authorize operations and receive no new writes.
Correction preserves the result and policy body, supersedes the policy, and allocates the existing unified successor with bounded manager feedback. After a new upstream generation is approved, subsequent deterministic derivation produces the next policy and links its predecessor. It may have the same canonical hash: new generation/approval custody identifies the replacement. A general unified correction also invalidates the predecessor's current upstream; subsequent post-policy derivation supersedes it atomically.
The policy operations consume the saved result without model, document or checker calls. AUTH-12G supplies authorization; POL-06B connects public manager decisions and approval-driven automatic derivation/recovery. Setup remains immutable. The existing complete proposal retains requirements, exact registered bindings, safe findings and non-executable capability suggestions. Evidence binds assigned original-document versions and hashes; model page/section attributions do not become verified judgments. Review display excludes credentials, private storage locators, signed URLs and raw source excerpts. No second derivation output or setup-summary state machine is introduced.
When a task locks project context, Workstream copies the canonical persisted
PostSubmitCheckerPolicy.policy_body and its exact hash. Submission and checker
runs copy that same body/hash. Later changes to a project's policy do not rewrite
those locked facts. Project policy versions describe changes to project rules;
they do not select different software readers.
Initial v0.1 has one supported body, compiler and catalogue. Earlier development representations reject; no migration reader, translation or fallback preserves them. Retained data and immutable evidence are not deleted or rewritten by this cleanup. New setup generations use the current contract; any data disposition requires separate authorization.
The canonical body contains:
schema_version:post_submit_checker_policycompiler_version:workstream-post-submit-compilerproject_idandguide_versioncatalogue_id,catalogue_source_version,catalogue_schema_versionandcatalogue_manifest_sha256- ordered
entries, with checker ID, definition/implementation identity, classification and closed configuration blocking_severities
Each mandatory entry has classification platform_default. The eight defaults
cannot be omitted, reordered or reclassified. The sole selectable structural
addition is check_acceptance_criteria_present, classified as project_required
or project_warning. Default/required/warning/execution lists are derived from
these entries; they are not another serialized policy body. Existing persisted
required/warning/blocking summaries must exactly match the parsed canonical body
at setup continuation, activation, task locking/reading, submission validation
and execution. A recomputed hash cannot make an unsupported body valid.
Each entry has this shape (illustrative entry, not a complete policy):
{
"checker_id": "check_submission_packet",
"definition_version": "v0.1",
"implementation_version": "workstream-structural",
"classification": "platform_default",
"configuration": {}
}The compiler rejects unknown selections, conflicting classifications, invalid
configuration, missing defaults and weakened blocking severities. The floor is
critical and high; projects may add stricter severities. Raw structural
warnings remain distinct from policy-adjusted blocking outcomes.
Post-submit checker policy governs durable internal checker runs after a submission is finalized. It does not replace the generated project pre-submit checker policy.
Post-submit policy hash, body and lock columns are explicit. Runtime records
fail closed when a task, submission or checker run lacks valid
locked_post_submit_checker_policy_* context. Earlier development rows are not
automatically backfilled into authority. Retained data disposition requires
separate authorization.
Policy custody binds the canonical body to the exact guide, source snapshot,
approved upstream chain and pre-submit checker bundle. Only one current
compiled or approved policy exists for a guide. Superseded rows preserve their
body/hash, supersession kind/reason and timestamp, with actor, grant and decision
provenance in exact append-only operation custody. Retained historical role
values remain inert. Replacement links follow approved upstream generations;
the canonical hash may stay the same. A correction targets the exact proposal
and policy, so a stale target cannot authorize a decision on a later generation.
human_review_required: bool = true is persisted in the existing immutable
guide-bound policy. Creation defaults true; updates that omit it inherit the
exact predecessor's value. Only JSON booleans are accepted. False is configurable
in draft, but guide activation rejects it until automated FinalAcceptance/CON
execution is available. No new policy entity or acceptance-mode enum is added.
semantics_format pins the hash representation to the immutable version.
Existing rows are backfilled with v1 and true without changing their stored
hash, completeness status or downstream selectors. v1 retains its original
workstream.review_policy.v1 hash input, which excludes the new field; it cannot
represent false. New rows use v2, whose workstream.review_policy.v2 digest
includes the explicit boolean. Neither format repairs incomplete semantics.
The migration's boolean backfill default is removed afterward; API/ORM creation
defaults true, and direct SQL must provide a non-null boolean. Downgrade refuses
any v2 history, including true, because removing the format would lose meaning.
The implementation record binds the configuration proof. Automated routing and final acceptance remain separate work; existing attempts retain their exact locked policy versions.
Fields:
idproject_idguide_versionpolicy_generationpolicy_hashhuman_review_required: strict boolean, creation defaulttruesemantics_format:v1 | v2, immutable hash representationsemantics_status:complete | legacy_incompletesupersedes_policy_idreview_preference_window_secondsreview_lease_duration_secondsmax_active_review_leases_per_reviewer:1in v0.1self_review_allowed:falsein v0.1reject_policy:close_taskin v0.1finding_evidence_requirementallowed_decisionsminimum_finding_fieldscreated_at
Fields:
idproject_idguide_versionpolicy_generationpolicy_hashsemantics_status:complete | legacy_incompletesupersedes_policy_idmax_revision_roundsrevision_deadline_hoursallowed_resubmission_statesreviewer_reassignment_rulecreated_at
Limit or deadline exhaustion blocks further preparation and submission; it does not synthesize a reject Review. Complete next-attempt context selection is deterministic: exact prior component matches keep, every changed valid active guide/policy component rebases together, and missing or unsafe active context blocks for manager repair.
Fields:
idproject_idnamestatus:draft | active | retiredcurrent_published_version_idlast_transition_operation_idcreated_bycreated_atretired_byretired_at
At most one policy is active for guide activation in one project. Guide activation and task readiness require its published version; missing configuration is not an implicit unpaid rule. Later TaskAssignment and ReviewLease creation copy the attempt's locked version even if it has since been retired.
Fields:
idcontribution_policy_idproject_idversion_numberstatus:draft | published | retiredlast_updated_byandlast_updated_atfor the authorized complete-draft replacement anchorlast_transition_operation_idfor database-verifiable publication or retirement custody- publication and retirement actor/timestamp fields
Published and retired versions are immutable. Guide activation binds one version; WorkstreamTask locks it before claimability, TaskAssignment copies it, Submission stamps the attempt value, and ReviewLease copies that immutable stamp.
Each policy mutation appends one immutable event containing the operation and request digest, actor/project/policy/version identity, version number, prior published-version identity, exact policy/version state transition, and database-owned occurrence time. PostgreSQL rejects event update, delete, and truncate. Exact operation replay may return only this immutable result after a fresh authorized read; it never reconstructs success from mutable policy state. Publish and retire events additionally carry a conditional publication-custody operation reference; draft events never carry it.
Each publish or retire operation owns one immutable custody row binding the operation/request digest, actor, project, policy, target version, optional prior current version, event type, and database-generated occurrence time. Deferred PostgreSQL guards require the aggregate, affected versions, and lifecycle event to carry the same unique transition operation. Replacement publication retires the prior version with the same actor and time. Custody rows reject update, delete, and truncate and roll back with product state and authorization evidence.
Fields:
idcontribution_policy_version_idproject_idcontribution_type:accepted_submission | completed_reviewcompensation_mode:compensated | unpaid
Every publishable version contains exactly one rule for each contribution type.
An unpaid rule has no award definitions. A compensated rule has one or two:
at most one money and one project_points definition.
Fields:
idcontribution_rule_idcontribution_policy_version_idproject_idcontribution_typeinstrument_type:money | project_pointsunit_codequantityin the exactNUMERIC(38, 18)value envelope, stored unrounded and checked explicitly before persistenceadapter_binding_id
API quantities are bounded decimal strings; binary floating point, exponent
notation, non-finite values, zero, negatives, overflow, and excess precision
are rejected rather than rounded. Money units are uppercase configured ISO 4217
codes. Project-points units have project-scoped identity
(project_id, unit_code) and whole-number quantities. Published definitions are immutable and project,
instrument, and unit consistent with the referenced adapter binding.
Fields:
project_idinstrument_type:money | project_pointsunit_codeiso_currency_codefor money, null for project pointsstatus:active | retired- creation and retirement actor/timestamp fields
The identity is (project_id, instrument_type, unit_code). Money units reference
the migration-owned immutable ISO 4217 List One registry. Project-points units
are project-scoped. Award definitions reference the unit identity with a
composite foreign key. Persistence initially allows active creation only and
defers unit lifecycle mutation to the authorized contribution-policy behavior.
Fields:
idproject_idinstrument_type:money | project_pointsadapter_actor_idroute_keystatus:active | suspended; retirement remains a future lifecycle extensionbinding_lifecycle_version, starting at 1 and incrementing once per valid active-to-suspended or suspended-to-active transition- creation, suspension, resume, and retirement actor/timestamp fields; only the current suspension or resume attribution is populated after version 1
route_key is a non-secret 1-120 character ASCII identifier matching
^[A-Za-z][A-Za-z0-9._:-]{0,119}$; traversal pairs, whitespace, path/URL/query
syntax, controls, and Unicode are forbidden. Provider endpoints, credentials,
and tokens are deployment secrets, not domain fields. At most one binding is
active per project and instrument. CP02 installs hidden, route-unreachable
create/read/suspend/resume behavior and immutable transition events while AUTH
actions remain unavailable. Retirement is not implemented.
Fields:
idproject_idguide_versionsourcelesson_typesummaryrecommended_changestatuscreated_bycreated_atclosed_at
Lesson types:
- guide_update
- checker_update
- reviewer_policy_update
- revision_policy_update
- queue_policy_update
- contribution_policy_update
- risk_note
Status:
- open
- accepted
- rejected
- implemented
Activation chronology in the Task, Submission and RevisionContextPreparation
sections is a future lineage contract, not a claim that those activation
fields are implemented. CP07 persists ProjectGuide.activation_operation_id
and its immutable activation receipt/generation; it creates no activation-sequence
counter. The downstream ...activation_sequence names below are planned
chronology fields, not references to an existing ProjectGuide source column.
Before implementing or exposing those fields, the Task/Submission and revision
chunks must reconcile the authoritative chronology source and immutable
same-project references with CP07 custody, and implement source and stamps
together. Guide version strings are not chronological counters. ADR 0010's
planned revision behavior remains normative; this clarification does not choose
a new chronology mechanism or claim downstream runtime integration.
Fields:
idproject_idlocked_guide_idlocked_guide_versionlocked_guide_activation_sequence(planned; see the future lineage contract above)locked_guide_source_snapshot_idlocked_guide_source_snapshot_hashlocked_effective_project_submission_artifact_policy_idlocked_effective_project_submission_artifact_policy_hashlocked_pre_submit_checker_policy_idlocked_pre_submit_checker_bundle_hashlocked_post_submit_checker_policy_idlocked_post_submit_checker_policy_versionlocked_post_submit_checker_policy_hashlocked_post_submit_checker_policy_bodylocked_review_policy_idlocked_review_policy_generationlocked_review_policy_hashlocked_revision_policy_idlocked_revision_policy_generationlocked_revision_policy_hashlocked_contribution_policy_version_idsource_typesource_refsource_payload_hashimport_batch_idexternal_task_idtitledescriptiontask_typedifficultyskill_tagsestimated_time_minutesstatusacceptance_criteriarejection_criteriadeadline_atcreated_byassigned_tocreated_atupdated_at
Status:
- draft
- screening
- ready
- claimed
- in_progress
- submitted
- evaluation_pending
- review_pending
- needs_revision
- accepted
- rejected
- cancelled
Source type:
- manual
- markdown_import
- csv_import
External origin adapters are later work. When added, they normalize into this task shape instead of creating a separate task lifecycle.
The task id points to the locked task contract. That contract includes the exact same-project guide ID/version/activation-sequence triplet, guide source snapshot id/hash, effective project submission artifact policy id/hash, generated project pre-submit checker policy id/bundle hash, post-submit checker policy id/version/hash, exact review and revision policy id/generation/hash identities, acceptance criteria, derived display summaries, and skill tags. Contributors submit against the task id; they do not restate policy identities.
locked_contribution_policy_version_id is copied from the then-active guide
when the Task first acquires its complete context lock, before ready
(the existing transition acquires it at screening). Later readiness checks
validate that frozen tuple, not equality to a newer active guide or global
policy selector. Ordinary claim never changes it. Human
needs_revision complete-context preparation is the only boundary that may
atomically rebase this field on the continuing Task for the next attempt, with
prior/next lineage recorded before contributor access.
Durable post-submit checker execution uses
locked_post_submit_checker_policy_id,
locked_post_submit_checker_policy_version, and
locked_post_submit_checker_policy_hash.
Contributor-facing task responses omit post-submit checker policy internals.
Fields:
idtask_idproject_idcontributor_idassigned_bysubmitter_contribution_policy_version_idassigned_ataccepted_atreleased_atstatus
The v0.1 baseline excludes the retired persisted human
owner to contributor_id. The non-null varchar(36) value is protected by
foreign key fk_task_assignments_contributor_id_actor_profiles, index
ix_task_assignments_contributor_id, and trigger
task_assignments_contributor_human. The trigger reuses invoker-rights function
public.require_human_actor_profile_reference() to reject service profiles.
It deliberately permits suspended and deactivated human profiles because this
column preserves historical attribution rather than current authority.
At initial claim, submitter_contribution_policy_version_id must equal the
Task's locked version. It remains fixed throughout that submission attempt.
Future human needs_revision complete-context preparation must replace the
current write-once guards before rebasing the continuing assignment field; ordinary publication,
task claim, submission, and review claim cannot change it.
Fields:
idtask_idtask_assignment_idcontributor_idversionstatussummarysubmission_bundle_admission_id(hidden canonical intake identity from WS-ARCH-001-02F; public cutover remains 02I)artifact_binding_id(hidden canonical byte binding from WS-ARCH-001-02F; public cutover remains 02I)artifact_content_id(hidden canonical immutable ART content identity from WS-ARCH-001-02F; public cutover remains 02I)submission_bundle_manifest_id(target server-generated manifest identity)pre_submit_evidence_set_id(target checker evidence identity)package_uri(legacy caller transport removed by WS-ARCH-001-02I, which implements the superseded WS-ART-001-05B cutover)package_hash(nullable legacy caller input removed by WS-ARCH-001-02I; never canonical)artifact_hash(legacy transitional column replaced by exact binding/content identity and removed separately after all readers cut over)artifact_hash_manifest(legacy caller manifest removed by WS-ARCH-001-02I)contributor_attestationlocked_guide_versionlocked_guide_idlocked_guide_activation_sequence(planned; see the future lineage contract above)locked_guide_source_snapshot_idlocked_guide_source_snapshot_hashlocked_effective_project_submission_artifact_policy_idlocked_effective_project_submission_artifact_policy_hashlocked_pre_submit_checker_policy_idlocked_pre_submit_checker_bundle_hashlocked_post_submit_checker_policy_idlocked_post_submit_checker_policy_versionlocked_post_submit_checker_policy_hashlocked_post_submit_checker_policy_bodylocked_review_policy_idlocked_review_policy_generationlocked_review_policy_hashlocked_revision_policy_idlocked_revision_policy_generationlocked_revision_policy_hashsubmitted_atlocked_atsupersedes_submission_idremediation_source_checker_run_id(checker-remediation submissions only)revision_context_preparation_id(human-Review revision submissions only)contribution_policy_version_id(immutable exact attempt policy copied from the TaskAssignment during Submission creation)
The submission contributor uses foreign key
fk_submissions_contributor_id_actor_profiles, index
ix_submissions_contributor_id, and trigger
submissions_contributor_human, backed by the same reusable lineage function.
The current Submission contributor_id uses the same migration, foreign-key,
and canonical-human trigger contract as TaskAssignment. Claim and submission
creation additionally lock and revalidate the caller's exact active human
ActorProfile and active issuer/subject identity link before locking the task
and active assignment. That transaction participant establishes current
identity eligibility only; project roles, grants, actions, and resource policy
remain owned by the authorization service.
The contributor first supplies one outer ZIP, summary, and attestation to
submission-bundle preparation. Workstream computes the exact archive identity,
server-generated semantic manifest, required-file/evidence facts, and immutable
pre-submit evidence set, then stores and verifies the bytes into a ready
admission. Final Submission creation supplies that admission identity and
summary/attestation context; Workstream assigns the submission version, creates
the exact artifact binding, and stamps locked guide source,
submission artifact, effective project policy, pre-submit checker, post-submit
checker, review, and revision policy provenance from trusted
task/project state. The contributor does not provide submission version, evidence
ids, checker results, checker run ids, guide versions, source snapshots,
effective project policy ids/hashes, pre-submit checker ids/bundle hashes,
post-submit checker policy ids/versions/hashes, exact review policy identities,
exact revision policy identities, provider references, package hashes, or
artifact manifests. Submitter award eligibility is governed by the
TaskAssignment-selected ContributionPolicyVersion for the exact attempt and
is not contributor-supplied. Submission creation stamps that identifier
immutably before any later rebase can change the continuing assignment. Human
revision preparation records prior/next policy lineage before it may update
that selector; publication alone cannot.
Version 1 has neither revision-source field. Every later version has exactly one:
a checker-remediation version stores the server-derived
remediation_source_checker_run_id, while a human-Review revision stores the
server-selected revision_context_preparation_id. The checker source must be the
completed, needs-revision, current-at-selection CheckerRun for the immediate
predecessor Submission and same Task. PostgreSQL enforces same-task/immediate-
predecessor lineage, one successor per source CheckerRun, source-field XOR, and
post-finalization immutability. A later CheckerRun retry cannot rewrite committed
Submission lineage. Contributor requests supply neither authoritative source ID.
Implementation note: submissions stamp explicit post-submit checker provenance
from the task. Durable CheckerRun creation uses those
locked_post_submit_checker_policy_* fields and fails closed when they are
missing, mismatched, deleted, stale, or unauthorized.
Contributor-facing submission responses omit post-submit checker policy internals.
Status:
- submitted
Submission status records the immutable packet version state. Task status carries evaluation, human review, revision, acceptance, and rejection lifecycle states.
Fields:
idsubmission_idtypelabelurihashsize_byteslocked_atmetadatacreated_at
Types:
- log
- screenshot
- test_result
- package
- diff
- note
- external_reference
ARCH-04C uses one run as the logical post-submit attempt. PostgreSQL preserves its project/task/Submission ownership, immutable canonical request and digest, request ID, generation, result ID, predecessor and locked policy identities. The exact request carries the selected ART binding/content and compiled policy; it does not create a second artifact manifest authority.
Key custody fields:
id,project_id,task_id,submission_id,submission_versionevaluation_request_id,phase,evaluation_generationrequest_json,request_digest,result_idworker_lease_id,worker_lease_generation,worker_lease_expires_atexecute_evidence_id,finalize_evidence_idsupersedes_checker_run_id, locked guide/post/review/revision identitiesstatus,started_at,completed_at,failure_coderesult_json,result_digest,material_custody,completion_event_idrouting_recommendation, member counts and execution provenance
States are queued -> running -> completed | infrastructure_failed. An expired
execution lease can be replaced without changing the request or attempt. Completed
and infrastructure-failed outcomes cannot be rewritten. Member results, terminal
facts and the shared-outbox completion event commit together; infrastructure
failure produces no routable completion event. Deletion and truncation reject.
CheckerSubmissionFence has one submission_id and exact current_run_id.
Only caller-owned coordination advances it, by one evaluation generation.
History derives attempt_number from that generation and
is_current_for_submission from a completed run matching the fence. Neither is
an independently mutable stored flag. Current-result consumers hold the caller
transaction while checking this fence; an old event is not perpetual authority.
Completed routing is allow_review, needs_revision or task_setup_blocked,
derived from the locked blocking severities and complete member set. Unfinished
or infrastructure-failed runs use not_evaluated. allow_review means no
blocking evaluation finding, never acceptance: later TASK routing follows the
locked human-review requirement, including shared authorized acceptance when
false. No human Review is invented for that branch.
Migration 0008 refuses nonempty checker history before DDL. It does not invent requests or erase retained evidence. Such an environment requires an explicit preservation design. Migration 0010 (ARCH-04D2) adds deferred receipt foreign keys and exact phase-specific audit validation for execute/finalize. Receipts bind the request, run, lease, result, material and original execution receipt. Unprovable retained receipts cause an atomic upgrade refusal; queued work is preserved. Production uses real action-specific AUTH/PREP with fresh live identity checks.
A result is one ordered, selected structural member of its exact owning run. Insertion locks the running parent; composite ownership binds run/task/Submission. The complete selected set must commit with the parent's terminal result. Partial members cannot commit, and completion prevents appends. Updates, deletion and truncation reject.
Fields:
id,checker_run_id,task_id,submission_id,member_orderchecker_name,definition_version,implementation_versionstatus,severity,code,failure_category, boundedcounterscreated_at
Member states are passed, warning or failed, with closed registered outcome
codes and categories. Policy blocking uses the locked severity selection,
including a warning if that policy makes its severity blocking. History derives
bounded messages and contributor visibility from these facts; arbitrary messages,
metadata and evidence links are not stored on checker results. Private request,
policy, receipt and material facts are excluded from public history projections.
Pre-submit evidence remains a separate intake contract and creates no CheckerRun.
Fields:
idchecker_idnamephasedefault_severitydefault_blocks_reviewversioncontributor_visibledescriptioncreated_atretired_at
Phase:
- project_activation
- task_screening
- submission_quality
- pre_review_gate
- lifecycle_transition
- compensation_fulfillment_reconciliation
The checker registry prevents project guide templates, checker policies, and implementation code from drifting into different checker names for the same rule.
pre_review_gate is a checker phase, not a task status. The v0.1 task status during this phase is evaluation_pending.
Current status:
Optional later record. v0.1 stores readiness proof on CheckerRun.
Fields:
idsubmission_idchecker_run_idsubmission_bundle_manifest_id(target if this deferred record is ever added)blocking_failures_countwarnings_countready_for_reviewissued_byissued_atinvalidated_at
Purpose:
If added later, the readiness certificate records the exact checker run and server-generated manifest/binding identity that allowed a submission to enter human review.
For v0.1, the final current CheckerRun is the checker proof. ARCH-04E1A adds
the TASK-owned immutable task_post_submit_routing_manifests table as
route-neutral source evidence. It binds the exact Submission/assignment/
contributor/contribution-policy lineage, CHECKERS run/request/generation/result,
completion event and execute/finalize receipts, locked
human_review_required scalar, and canonical ART material identity. Detached
TaskPostSubmitManifestFacts additionally joins the predecessor, ART admission/
binding/content anchors and complete locked policy lineage; its sole
recommendation is allow_review, which is evidence rather than permission.
The table has no general routing publication writer/reader, current pointer,
handler or routing authority. REV-04C uses its bounded exact-source verifier.
TaskAcceptedEffectsPort is the source-neutral contract used
by the REV-04C hidden FinalAcceptance/TASK/CON participant. That participant is
not a complete authorized operation or live route. The valid storage graph is
currently limited to true policy. False is proven only as a strict scalar DTO
value because guide activation still rejects it.
Before publication, ARCH-04E1B/04E2 must harden this same table with mandatory
exact routing and owner-receipt custody. The migration must refuse every retained
pre-authority row; it may not backfill, mutate or delete one, and no parallel
manifest table is allowed. Later routing will publish the hardened source,
current pointer and review_pending transition atomically after currentness and
authority checks. Any submitted artifact change requires a new Submission and
checker run.
ReviewQueueEntry immutably anchors one exact finalized Submission/version,
Task, project, and its current successful allow_review CheckerRun. The 03A1
foundation does not yet consume the delivered ARCH-04E1A source table;
live admission must consume its later authority-hardened TASK handoff while
retaining these immutable CheckerRun/binding anchors. This adoption is an upstream dependency,
not activation of REV behavior. The 03A1
foundation persists only pending and closed queue state plus open/preferred
routing metadata; it exposes no route, selection behavior, or lease shape.
PostgreSQL validates the cross-owner lineage and checker admissibility when the
queue identity is written. The immutable queue row preserves that admission
fact if an upstream current-checker pointer changes later; it does not constrain
later mutations of upstream-owned rows.
ReviewAdmissionIdempotencyRecord reserves one exact admission operation and
SHA-256 request digest. It may begin pending without a queue, but can become
committed only when it references the matching queue identity and the same
completed, current allow_review CheckerRun. This is replay persistence, not an
automatic checker hook or authorization decision.
The later reviewer current-work API returns an active lease, one server-selected offer, or none; it never exposes the full backlog.
ReviewLease is the permanent identity of one claim attempt. It stores the
canonical human reviewer ActorProfile ID, queue/Submission lineage, database
lease times, disposition, and the ContributionPolicyVersion copied from the
immutable Submission attempt stamp during claim, transitively inherited from
Task/Assignment without current-policy lookup. PostgreSQL enforces one active lease per reviewer and
queue entry. The queue's deferred active_lease_id relationship must agree
with the single active lease at transaction commit, allowing later claim and
close commands to stage both sides atomically without exposing behavior in the
persistence chunk.
Fields:
idreview_queue_entry_idproject_idtask_idsubmission_idsubmission_versionreviewer_idreviewer_contribution_policy_version_idattempt_generationstatusclaimed_atexpires_atclosed_atclose_reason
Status is active, consumed, released, expired, or revoked. An active
attempt has no close fields. Terminal close provenance is exact:
review_recorded, manual_release, lease_expired, grant_revoked, or
admin_override. Identity, queue/Submission lineage, reviewer, frozen policy,
generation, and lease times never change; terminal attempts are wholly
immutable. The reviewer policy FK is non-null and same-project through CON's
canonical ContributionPolicyVersion(id, project_id) identity. Claim copies
the exact version stamped on the admitted Submission/task attempt; it performs
no current-policy lookup. A version that was published when the attempt was
prepared remains valid for that attempt after later retirement or publication.
REV's database guard rejects a draft, crossed-project, or lineage-mismatched
identity. Reviewer and preferred-reviewer FKs accept only canonical human
ActorProfiles.
ReviewPacketManifest and ReviewPacketGuideItem provide immutable REV packet
storage. The header binds one lease/queue to the exact Submission/version,
admitting checker run/aggregate result, locked guide/snapshot and activated
setup run/generation. It contains exactly one original ZIP binding. Normalized
members identify each declared source item and live guide ingest, source order,
role and media type. PostgreSQL reconciles the complete set and committed uploads.
The header's semantic packet_manifest_digest covers the full ART membership;
packet_manifest_generation equals the lease attempt generation. created_at
is database-owned. No artifact content hashes, sizes, provider locators, receipts,
source bodies or AUTH capabilities are copied. Header, members and ingests reject
mutation/deletion/truncation. Repository writes are caller-transaction operations;
creation checks the lease deadline against PostgreSQL time; exact replay retains
the stored identity after expiry or closure. The detached identity is
packet_manifest_id, matching AUTH. This storage is delivered; the resolver,
claim authority and byte capability remain future work. REV-04A immutable Review source storage, REV-04B FinalAcceptance persistence and
REV-04C hidden acceptance/TASK/CON participation are delivered. Hidden routing
handlers are next; exact authority, complete-effect custody and activation
remain required before production use.
REV-04A delivers immutable source storage, not an authorized decision writer. The change contract defines exact columns, limits, digest formats and proof boundaries.
A Review retains its project, task, exact Submission/version and assignment,
reviewer, lease, queue and immutable packet identity/digest; the canonical ART
ZIP hash; the Submission's locked guide and ReviewPolicy identity; and the
lease-frozen ContributionPolicyVersion. It stores only accept,
needs_revision, or reject, a bounded summary, child counts, the complete
aggregate digest and one PostgreSQL-owned completed_at timestamp. The summary
is the required human reason for reject. There is no draft Review, confidence
score, arbitrary evidence-reference array or direct creation endpoint.
The predecessor is the nearest Review on the same-task Submission predecessor
chain, including across checker-only corrections. It must be needs_revision;
a null predecessor means no reviewed ancestor. Unique Submission, lease, packet
and non-null predecessor keep the retained Review chain unambiguous.
Creation requires an active unexpired lease using database time. The transaction must finish with that lease consumed and its queue closed for review_recorded. Storage tests prove these relations; they do not substitute for the still-required AUTH, CON, shared fence and lifecycle participants in a canonical decision.
A finding stores its UUIDv7 id, owning Review, zero-based order, blocking or
advisory kind, area, issue and required fix. A resolution stores its UUIDv7 id,
resolving Review, prior finding, order, resolved, unresolved or
not_applicable result, and bounded rationale. Both inherit completion time
from the owning Review and grant no evidence-upload authority.
Every open inherited blocking finding needs a current resolution. A finding closed by resolved/not_applicable cannot reopen; an unresolved result carries it forward. Accept leaves no new or inherited blocker open; needs_revision leaves at least one. At most 100 blockers may remain open, preserving bounded resolution capacity. Counts distinguish new findings from current resolutions. The exact complete ordered children are sealed by the Review's digest; late inserts, updates, deletes and truncation are rejected by PostgreSQL.
An immutable completed association binds project, reviewer, caller idempotency key, operation UUID, stable request digest and exact Review. There is no pending state or AUTH/CON placeholder. The request and Review commit or roll back together. The request digest excludes newly generated record IDs and timestamps so exact concurrent first deliveries match. The separate aggregate digest includes retained Review/finding/resolution IDs. Runtime replay and decision authority remain later work; the stored key does not grant authority.
This remains planned with the revision preparation owner. It will bind the assigned contributor's bounded response text, exact preparation head, prior finding and new Submission. REV-04A does not add an unchecked preparation UUID or claim response admission. Its structural FindingResolution relation must be composed with that future custody before revision decisions are activated.
Separate reviewer-finding or contributor-response artifact uploads are excluded from v0.1. No ReviewEvidenceArtifact table is implemented or required by this storage boundary; any future upload capability needs a separate reviewed intent.
Prior/next activation chronology remains subject to the future lineage contract described under Task; these fields are not delivered by CP07.
Fields:
idtask_idoriginating_review_idsource_task_assignment_idtarget_task_assignment_idprior_submission_idprior_submission_versionnext_submission_versionprior_locked_guide_idprior_locked_guide_versionprior_locked_guide_activation_sequence(planned chronology)prior_locked_guide_source_snapshot_idand hashnext_locked_guide_idnext_locked_guide_versionnext_locked_guide_activation_sequence(planned chronology)next_locked_guide_source_snapshot_idand hash- prior and next locked submission-artifact-policy identity and hash
prior_locked_effective_project_submission_artifact_policy_hashnext_locked_effective_project_submission_artifact_policy_hash- prior and next locked pre-submit-checker policy identity, version, and hash
prior_locked_pre_submit_checker_bundle_hashnext_locked_pre_submit_checker_bundle_hash- prior and next locked post-submit-checker policy identity, version, and hash
prior_locked_review_policy_id, generation, and hashnext_locked_review_policy_id, generation, and hashprior_locked_revision_policy_id, generation, and hashnext_locked_revision_policy_id, generation, and hash- prior and next locked task-template and task-execution policy context
prior_submitter_contribution_policy_version_idnext_submitter_contribution_policy_version_idoutcome:kept | rebased | blockeddirection:forward | backward | nullcontext_digestpredecessor_preparation_idpreparation_sequencerebase_reasonchange_summaryprepared_byaudit_event_idcreated_at
Purpose:
This immutable Review-rooted record is created atomically before a contributor can observe human-review-caused revision. Checker remediation retains the Task's locked context and creates no preparation. Preparation compares the prior Submission's complete stamped context with every applicable currently active Project Guide and policy selector: guide identity/version/activation sequence, source snapshot, submission-artifact policy, effective project policy, pre-submit and post-submit checker policies, ReviewPolicy, RevisionPolicy, task-template/task-execution context, and the ContributionPolicyVersion in the attempt's locked context. At this human revision boundary, TASK validates the complete currently active project context through owner ports, including CON's policy-validation port. An exact component match is kept; every changed valid component is rebased together for the next attempt. Missing, incomplete, inconsistent, crossed-project, revoked, or otherwise unsafe context blocks the whole preparation for manager repair. Task Context returns only the validated complete chain head. No context rebase occurs during active review; the reviewer reads the context stamped on the leased Submission.
Publication never silently rebases award eligibility during active or completed
work. After a human needs_revision, revision preparation records prior and
next ContributionPolicyVersion references and atomically updates the
continuing Task and TaskAssignment only for the next submission attempt when
the complete current context changed. Prior Submissions, ReviewLeases, Reviews,
ContributionRecords, and CompensationAwards retain their old version. The next
Submission stamps the rebased version, and its ReviewLease copies that version.
The contributor and reviewer history show prior/next guide, policy—including ContributionPolicyVersion—identity, activation sequence where applicable, direction, reason, and change summary.
The shared acceptance contract
defines both sources for this REV-owned fact. REV-04B delivers its immutable
storage foundation; REV-04C supplies the hidden mechanical writer/participant,
while the complete authorized operation remains planned. One schema and operation serve human accept and authorized task.post_submit.route with the
exact current successful routing manifest, locked human_review_required=false
policy and originating AUTH decision event. Required-check success or raw checker
output alone cannot create FinalAcceptance. No separate automated decision entity
or synthetic Review is introduced.
Fields:
idproject_idtask_idsubmission_idsource_review_idacceptance_source:human_review | task_post_submit_routesource_routing_manifest_idauthorization_decision_event_id— mandatory future runtime custody, not yet in the storage foundationaccepted_submitter_idaccepted_atrecorded_bypolicy_context_ref
Purpose:
The REV-04C participant creates or exactly replays this immutable REV-owned fact
inside either caller-owned transaction and composes TASK/CON effects. It has no
authority receipt, routing handler or production consumer, so it cannot be
consumed as canonical acceptance.
Before runtime, a same-table hardening migration must add exact mandatory AUTH
custody and refuse retained pre-authority rows without backfill or deletion. Existing Submission is already the version
identity, so the stored FK is submission_id; no SubmissionVersion entity or
submission_version_id alias is introduced. recorded_by is the originating
AUTH actor: the actual reviewer or the admitted fixed TASK routing service.
policy_context_ref is a foreign key to the exact immutable ReviewPolicy.id
whose project and guide version match the reviewed Submission context.
PostgreSQL enforces UNIQUE(task_id), UNIQUE(submission_id) and uniqueness
of each non-null source, closed/exclusive source shapes, plus the canonical
same-chain and immutable source constraints. There is no public/manual create API and no separate
authorization action. needs_revision and reject create none. Accept/reject
are terminal in v0.1; no adjudication or replacement-acceptance path exists.
Reviewer-quality sampling is a non-mutating audit and never delays or changes
this record.
CON-03C implements this immutable storage foundation. CON-07 adds the hidden submitter participant and complete frozen award staging/replay in the caller's transaction. REV-04C composes it with hidden FinalAcceptance/TASK effects. Source AUTH hardening, database complete-set enforcement, currentness proof and runtime composition remain unavailable; reviewer participation and fulfillment are separate future work.
Fields:
idproject_idtask_idsubmission_idcontribution_type:completed_review | accepted_submissioncontributor_idsource_review_idsource_review_lease_idsource_final_acceptance_idsource_task_assignment_idartifact_hashcontribution_policy_version_idcreated_at
Purpose:
The record is immutable. Every valid recorded human Review creates one reviewer
completed_review contribution with direct Review and ReviewLease lineage.
Review(accept) creates FinalAcceptance; exactly one submitter
accepted_submission consumes that fact plus the exact TaskAssignment.
needs_revision and reject create no FinalAcceptance or submitter record.
Reviewer rows require source_review_id and source_review_lease_id and have
null FinalAcceptance/assignment sources. Submitter rows require
source_final_acceptance_id and source_task_assignment_id and have null
direct Review/lease sources. Unique constraints on the nullable source IDs enforce one
completed_review per Review and one accepted_submission per
FinalAcceptance; database checks reject mixed or incomplete source shapes. The
record carries the exact Submission, actor, frozen contribution policy, and
stabilized artifact-hash lineage. Compensation awards may reference it but do
not replace it; reputation projection remains deferred.
CON-03C implements immutable exact-definition storage; no payment/points delivery or runtime creation is activated.
Fields:
idproject_idcontribution_record_idcontributor_idcontribution_policy_version_idaward_definition_idadapter_binding_idinstrument_type:money | project_pointsunit_codequantityas the definition's exact unscaled PostgreSQLNUMERIC, bounded to 20 integer and 18 fractional digits without roundingcreated_atcorrelation_id
The award is immutable and copies its instrument, unit, quantity, and binding from the published definition without conversion or rounding. Explicit unpaid rules create no award. At most one award exists per contribution and instrument type; fulfillment state is not stored on the award.
Fields:
idcompensation_award_idproject_idadapter_binding_idexternal_event_idreported_status:fulfilled | failedexternal_referencefulfilled_quantityfulfilled_atfailure_codereported_atreceived_atcorrelation_id
Receipts are immutable. external_event_id is a binding-scoped unique 1-128
character opaque ASCII token from [A-Za-z0-9._:-]. Fulfilled receipts require
the exact award NUMERIC(38, 18) quantity, a non-secret external reference with
the same bounds, and a timestamp. Failed receipts require a closed Workstream
failure code and null quantity, time, and external reference. Free-form provider
messages/codes, payloads, headers, signatures, credentials, URLs, and metadata
are never persisted, logged, emitted, exported, or returned. One award has at
most one fulfilled receipt.
Fields:
compensation_award_iddelivery_status:pending_delivery | acknowledged_by_adapterfulfillment_status:pending | failed | fulfilledlatest_receipt_idexternal_referencelast_failure_code- delivery, fulfillment, and update timestamps
This projection is mutable and rebuildable. ContributionRecord, CompensationAward, outbox delivery history, and fulfillment receipts remain the authoritative records.
Fields:
idactor_idtask_idsubmission_idcontribution_record_idevent_typeskill_tagsweightscore_deltareasoncreated_at
Event types:
- accepted
- needs_revision
- rejected
- revision_closed
- contribution_recorded
- compensation_fulfilled
- review_quality_sampled
- review_feedback_flagged
This entire record is deferred to a separate reputation initiative. Future review-quality inputs are offline non-product evidence: they cannot alter an immutable Review, create another product decision, or introduce adjudication state.
Fields:
identity_typeentity_idevent_typefrom_statusto_statusactor_idexternal_subjectexternal_issueractor_rolesclaim_snapshotauth_sourceis_dev_authreasonevent_payloadcreated_at
Audit events are append-only.
Authority evidence extends the same row with event_domain, event_version,
database-owned occurred_at, request/correlation IDs, an actor-reference
namespace, and optional bounded target actor, matched grant, permission,
project, resource, denial, invalidation, idempotency-reference, and shallow
before/after fact fields. It does not create a parallel event table.
actor_roles, claim_snapshot, and event_payload are legacy-only data
surfaces. Authority rows keep them at [], {}, and {} respectively, use
auth_source = local_authority, and leave external issuer, external subject,
and lifecycle status fields null. They never store tokens, claims, emails,
request bodies, issuer URLs, key material, or policy bodies. Typed validation
and database constraints reject mixed legacy/authority shapes.
v0.1 audit storage is the existing Workstream audit_events ledger. Task
Lifecycle events and authority events share the canonical audit repository so
operators can reconstruct why an actor was allowed or denied. Authority events
record bounded actor, matched grant/permission, scope, resource, reason, and
before/after facts without raw claims or unnecessary profile data. The shared
repository participates in its caller's transaction and does not commit or
open an independent session.
The typed LifecycleAuditParticipant is the feature-neutral writer for new
REV/CON lifecycle evidence. It accepts only closed entity/reason/reference
types and UUID references, flushes through the caller's AsyncSession, and
uses the existing lifecycle-compatible audit_events representation without
adding another domain or ledger. Its persisted compatibility discriminator is
legacy_lifecycle; that storage token is not the name or ownership boundary of
the new typed interface. The participant supplies fixed internal provenance
markers required by the existing representation; callers cannot provide
external subjects, issuers,
roles, claims, authorization facts, credentials, provider references, or
arbitrary payload metadata. Exact event-ID replay returns only an identical
immutable row, while changed reuse fails closed. Caller rollback removes the
audit row with the rest of the product transaction. The nested project_id
reference is provenance evidence only: it must never be used as an
authorization scope or query filter. Every reader must reload the canonical
entity relationships to establish the event's project context.
Lifecycle event tokens are added only when an adopted feature contract defines
them, together with their closed primary-entity pairing and contract tests.
- a task must belong to a project
- a task records the project guide version used at creation
- a task cannot enter ready without passing screening; recovery uses only its registered scoped permission and cannot bypass missing task policy context
- a submission must belong to a task
- a review must belong to a submission
- an accepted task must have exactly one FinalAcceptance linked to its versioned Submission and exactly one accepting source: human accept Review or authorized locked-false TASK routing manifest
- every valid recorded human review must create one reviewer
completed_reviewcontribution - an accepted task must additionally create one submitter
accepted_submissioncontribution sourced from FinalAcceptance needs_revisionandrejectmust not create FinalAcceptance or a submitter contribution- FinalAcceptance is unique per task, Submission and each non-null source and has no independent creation API/action
- v0.1 has no adjudication state/action/queue/lease/decision/contribution or readiness dependency
- no compensation award exists without its contribution record
- a fulfilled award must have an immutable fulfillment receipt with the exact authorized quantity and external reference
- review-lifecycle v0.1 creates no reputation event; future reputation records must consume canonical contribution/review lineage without mutating it
- compensation award quantity is immutable after creation
- failed fulfillment may later receive one valid fulfilled receipt; a fulfilled award is terminal and rejects conflicting callbacks
- the mutable compensation projection never overrides award or receipt truth
- critical- and high-severity checker failures block review; registered recovery may retry or repair infrastructure but cannot create a review decision or erase checker evidence
- a checker run must reference the exact submission version and artifact hashes it evaluated
- the current checker run is the v0.1 readiness proof for the submission version that cleared automated checks
- a review cannot accept a submission if the checker run belongs to a different submission version
- every status transition creates an audit event
- every needs-revision decision has at least one unresolved blocking ReviewFinding
- every revision context rebase creates an audit event and preserves prior submission context
- every accept decision cites evidence
- repeated review/checker failures become ProjectLesson records
- submission artifacts are immutable after
locked_at - a changed artifact requires a new submission version
- task lifecycle status and compensation fulfillment status remain separate
REV-12A1 adds joint_lifecycle_release_control: one UUIDv7 identity, true singleton
key, closed phase, nonnegative generation and database-owned creation time. The
seed is disabled at generation zero. INSERT, UPDATE, DELETE and TRUNCATE are
blocked after seeding; no usable generation or transition authority exists yet.
The REV public fence reads detached facts under a caller-owned root transaction,
acquiring its fixed advisory lock before the singleton row lock. It neither
commits nor grants business authority. Later authorized transitions extend this
same controller. Fulfillment roots, ordinals, cutoffs and phase history remain
unimplemented; they are not fields on an award or a substitute outbox record.
task_post_submit_routing_requests is immutable coordination custody, separate
from the retained source manifest. route_operation_id is its generated UUIDv7
primary key; routing_manifest_id reserves the future source identity and is
unique. Neither is derived from the checker request or a content digest.
The row binds project/task/Submission/version, checker run, evaluation request/
digest/generation, result ID/digest, completion event and literal allow_review.
The route-request digest hashes that closed selection with its own domain/action;
allocated IDs and database creation time are excluded. The completion event and
(submission_id, checker_run_id, result_digest) each have unique constraints.
Insert custody locks Task, latest submitted Submission, CHECKERS fence and run in that order, verifies canonical receipts/material and the immutable completion event, and recomputes the digest. Updates, deletion and truncation are rejected. This row grants no authority and publishes no routing source or outcome. Future source publication must enforce the reserved manifest identity together with its actual AUTH receipt and governed consequence.