This is the canonical repository specification for the target Workstream
authorization service. It reconciles the adopted archival WS-AUTH-001 input
with ADR 0006, ADR 0012, the existing /api/v1 namespace, and current module
boundaries.
The current backend remains on a staged migration path until the owning WS-AUTH-001 implementation chunks merge. This specification must not be read as evidence that an unimplemented route or guard already exists.
The external Identity Issuer owns authentication. Workstream verifies its tokens and owns product authorization.
| Boundary | Owner | Rule |
|---|---|---|
| Login, passwords, primary sessions, token issuance | External Flow Identity Issuer | Workstream does not implement them. |
| Signature, issuer, audience, time, subject kind, coarse scope | Existing AuthVerifier adapter/dependency boundary |
Fail closed; pin algorithms and issuer configuration. |
| Actor identity and identity links | backend/app/modules/actors |
One canonical profile; issuer/subject links are explicit and revocable. |
| Grants, permissions, idempotency, invalidation, decisions | backend/app/modules/authorization |
Deny by default; no token-role product authority. |
| Resource facts | Owning feature services/repositories | Repositories return domain records; application services compose ResourceContext. |
| Review lifecycle | WS-REV-001 | Authorization supplies actors and permissions but does not invent review outcomes. |
| Contribution and compensation | WS-CON-001 | Authorization does not redefine contribution or compensation behavior. |
All public routes use /api/v1. The archival short prefix is not an alias.
Within the modular monolith, app.modules.authorization.api is the sole public
AUTH dependency boundary. Other modules do not import AUTH models,
repositories, evaluators, routers, sessions, or concrete services. AUTH also
does not import another product module's private implementation; later
capability repairs replace frozen legacy edges with that module's public typed
port. These in-process contracts are deliberately suitable for later HTTP,
gRPC, or asynchronous transport without changing product authority semantics.
VerifiedIssuerToken contains only verified identity and coarse-access data:
- canonical issuer;
- opaque subject;
- audience;
- issued-at, expiry, optional not-before;
- mandatory token identifier (
jti); - subject kind;
- verified coarse scope.
It contains no Workstream product role or permission. Email, display name,
skills, reputation, and relationship metadata are never authorization keys.
Canonical self-read is GET /api/v1/actors/me. Actor admission does not copy
issuer email or display name. Human-owned profile metadata is updated through
PATCH /api/v1/actors/me; verified issuer claims do not grant product roles.
Human first access may create a canonical human profile and identity link. Unknown service subjects, agents, and Spaces are denied without implicit provisioning. Service actors require explicit pre-provisioning.
ActorProfile is the canonical Workstream actor root.
Required concepts:
- UUID identifier;
- kind: human or explicitly provisioned service;
- fixed unique
service_identityfor a service and null for a human; - status: active, suspended, or deactivated;
- contributor domain for human self-service;
- database-time creation/update and immutable historical attribution.
A profile status is a guard, not a grant. Active humans receive only self
profile capability until an administrative or exact-project grant exists.
For a service, the profile is the stable local identity. Its immutable
service_identity is either action-bearing with one closed typed service-action
matrix row or target-only with no matrix row and no executable authority. The
identity kind is never inferred from display data, token claims, issuer, or
subject. Profile ID, service identity, and external credential binding remain
separate concepts.
An identity link binds one canonical issuer and opaque subject to exactly one profile. Link state is active or revoked. Raw tokens, provider credentials, and full provider claims are never persisted.
Existing classified external actor UUIDs may be preserved as profile IDs. Legacy typed workflow-profile IDs are unrelated and never promoted.
| Grant | Scope | Purpose |
|---|---|---|
access_administrator |
system | Actor, identity-link, and administrative-grant administration. It does not edit the closed permission/action catalog or action availability. |
operator |
system | Runtime inspection and explicit recovery operations against canonically resolved resources. |
project_manager |
system or exact covered project | Project, task, guide/setup, submission/checker, review, and revision configuration plus contributor grants. It cannot mutate contribution policy or compensation-adapter bindings. System scope covers all projects but remains resource- and lifecycle-guarded; exact-project scope covers only that project. |
finance_authority |
system or exact covered project | Contribution policy, compensation-adapter binding, and fulfillment observation owned by WS-CON. |
audit_authority |
system or exact covered project | Read-only evidence access and authorized export. |
Administrative grants do not imply contributor capability. An administrator cannot submit or review by administrative role alone.
| Grant | Exact-project capability |
|---|---|
submitter |
Minimal project read, task queue read/claim, own submission create/read, own review-chain read. |
reviewer |
Minimal project read, review queue/claim/release/decision, submission read for review, review-chain read. |
Contributor is the umbrella human product term. A contributor may hold
independent exact-project submitter and reviewer grants.
Holding multiple rows does not bypass separation-of-duties or lifecycle guards.
Celery, checker, setup, and background workers are internal services, not human
product roles.
Grants are immutable history. Issue and revoke target one exact role; one role never replaces another. Regrant after revocation creates a new immutable row. No observed token role, typed profile, skill, qualification, or reputation value creates a grant automatically.
The active model has no both, replacement field, replacement event, or
replacement reason. Qualification evidence is bound to the same actor, project,
and exact requested role. One active row is permitted per
actor/project/role. Issue idempotency includes the requested role; revoke derives
the role from the locked grant. The v0.1 baseline excludes obsolete
combined or replacement evidence exists and never converts or deletes those
rows. It replaces current typed and PostgreSQL validators without changing
historical migrations.
AUTH owns the closed PermissionId/ActionId catalog, exact mappings, and action
availability. No human administrative grant edits catalog definitions or moves
an action between planned and active.
The initial registered catalog includes:
actor.profile.read_self
actor.profile.update_self
actor.profile.read_any
actor.profile.suspend
actor.profile.reactivate
actor.profile.deactivate
actor.identity_link.read
actor.identity_link.revoke
actor.identity_link.reactivate
actor.service.provision
admin_role.read
admin_role.grant
admin_role.revoke
project.create
project.read
project.setup_diagnostic.read
project.effective_policy.read
project.update
project.archive
project.guide.manage
project.guide_compilation.request
project.guide_compilation.execute
project.effective_policy.manage
project.task.manage
project.review_policy.manage
project.role_grant.read
project.role_grant.manage
task.queue.read
task.claim
submission.create
submission.read_own
submission.read_for_review
review.queue.read
review.queue.inspect
review.claim
review.release
review.decline_preference
review.decision
review.lease.force_release
review.chain.read
review.queue.override
contribution.read_self
contribution.read_project
compensation.policy.manage
compensation.adapter_binding.manage
compensation.award.read
compensation.delivery.reconcile
operations.status.read
operations.timer.run
operations.reconcile.run
operations.outbox.retry
outbox.dispatch
operations.projection.rebuild
operations.task.start_override
operations.submission_gate.repair
operations.checker.retry
artifact.binding.read
artifact.replica.read
artifact.receipt.read
artifact.verification_job.read
artifact.verification_job.retry
artifact.recovery_attempt.read
artifact.audit.read
artifact.guide_source.ingest
artifact.binding.create
artifact.verification.execute
artifact.pending_work.scan
artifact.put_attempt.resolve
artifact.guide_source.read
artifact.checker_input.materialize
artifact.checker_output.write
artifact.review_packet.materialize
audit.read
audit.export
Artifact permissions are deliberately resource- and operation-specific.
artifact.*.read permissions do not authorize retry or recovery, human
Operator permissions do not authorize internal execution, and internal service
permissions do not authorize Operator APIs. AUTH-07A owns this closed registry,
AUTH-07B introduces the central kernel, AUTH-08 owns the Operator grant
definitions, AUTH-09A owns the static service-action matrix, AUTH-09B provisions
service ActorProfiles and ActorIdentityLinks, AUTH-09E admits fixed services,
and WS-ART consumes the resulting decisions without registering permissions or
inferring authority. Artifact actions follow AUTH planned
registration, hidden ART behavior/resource composition, then dedicated AUTH
evaluator integration and activation. ART never writes availability. AUTH-12,
AUTH-14, and AUTH-15 are not alternate artifact activation paths.
These are 75 approved PermissionId values. ActionId values are a separate
closed registry layer and are not included in that permission count. AUTH-05A's
typed and PostgreSQL audit registry accepts the exact historical 49. The three
approved Operator recovery identifiers, 16 artifact identifiers,
review.queue.override, and the two AUTH-11A read-only project inspection
permissions plus the two compilation permissions and the now-active
outbox.dispatch permission form the first 25 post-0020
permissions. ARCH-03C1 adds task.assignment.authority_reconcile as the 26th
post-0020 permission. AUTH-07A, AUTH-11A, and
WS-XINT-002-01 add
their matching typed/SQL audit parity without making them executable.
The closed action registry contained 78 rows after AUTH-11C2: 37 active actions
and 41 planned rows before AUTH-12A. AUTH-12A added eighteen planned
project-mutation rows, producing the historical 96-row state of 37 active and
59 planned. Later project-mutation and ART activation chunks advanced the
pre-02C state to 45 active and 51 planned. WS-XINT-003-02C adds four planned
REV rows. Subsequent approved activations advanced the pre-12I catalogue to 52
active and 48 planned rows. AUTH-12I adds and activates the two compilation
request/execute rows, producing 102 rows. WS-ARCH-001-02G subsequently
activates the existing contributor-preparation row, producing 55 active and 47
planned rows without adding an action or permission. WS-ARCH-001-02H activates
the existing human submission.create and fixed-service
artifact.submission.binding.create rows, producing 57 active and 45 planned
rows without adding an action or permission.
WS-ARCH-001-CP01A then adds four planned/unavailable adapter-binding actions,
producing 106 rows: 57 active and 49 planned. They map only to
compensation.adapter_binding.manage; no retirement, evaluator, identity,
service-matrix row, route, or activation is added. WS-ARCH-001-CP01B adds five
planned/unavailable contribution.policy.* actions, producing 111 rows: 57
active and 54 planned. They map only to compensation.policy.manage; no
evaluator, identity, service-matrix row, route, migration, or activation is
added. WS-ARCH-001-CP01C then corrects only the unavailable adapter-binding
resource facts: create binds the server-selected binding identity and no unit,
copies CON's exact instrument_type without translation, while suspend/resume
bind the exact positive lifecycle version. Catalogue
counts, mappings, owners, and availability remain unchanged.
WS-ARCH-001-CP03 is split after merged CP02 hidden behavior. CP03A adds only
the closed target identity workstream.compensation.adapter and real
PROJECTS/ACTORS eligibility adapters; it adds no service-matrix membership and
is complete while keeping all four binding actions unavailable. CP03B
then installs the exact read/PREP adapter for an authenticated human Finance
Authority covering the exact project and activates only those four actions,
producing 111 rows with 61 active and 50 planned actions. AUTH-12B2 then
activates exact setup finalization, yielding 62 active and 49 planned
actions without adding a row. CP05 activates the five existing ContributionPolicy
actions, yielding 67 active and 44 planned actions. POL-04B1 adds the automatic compilation
request action, historically making 112 actions: 68 active and 44 planned.
These are activation-history counts, not the current registry census. The
current typed catalogue also includes the TASK project-authority cutover.
Only active human
Finance Authority with system or exact-project scope is eligible. The explicit
CON adapter uses serialized reads and transaction-bound PREP for mutations;
committed replay requires fresh read authority. Registration custody remains
CP01B. No permission, service membership or policy HTTP route is added. Migration 0012_contribution_policy_audit_resource
adds the exact policy resource token and five existing action/permission pairs
to the two closed database audit constraints, preserving their other clauses. Downgrade refuses while policy audit history exists.
CP07A migration 0022_adapter_binding_audit_resource similarly admits the existing
compensation_adapter_binding resource and its read/create/suspend/resume action
pairs with compensation.adapter_binding.manage. It preserves all other audit
clauses and refuses downgrade while either a binding action or binding resource
remains in retained audit evidence.
AUTH-10A added five project-role read/manage rows;
AUTH-10B owns and activates the three reads, while AUTH-10C owns and activates
the two reason-bound, idempotent project-role mutations. AUTH-11A adds eleven
project identity and actor-context read rows: two are active under 11B, three
setup-diagnostic and three draft/effective-policy diagnostic reads are active
under 11C1, and three current effective-policy and active-guide reads are active
under 11C2.
AUTH-08 adds seven
active administrative definition,
grant-history, issue, revoke, and local-bootstrap actions without adding a
permission. AUTH-09A adds eight planned actor, identity-link, and service
provisioning actions without activating a route; AUTH-09B activates only
actor.service.provision, AUTH-09C activates only actor.profile.read and
actor.identity_link.read, AUTH-09D-A activates the three profile lifecycle
actions, and AUTH-09D-B activates the two identity-link lifecycle actions. The
other registry rows cover three planned Operator recovery actions and the ART
catalogue: 16 planned, three active foundation-service actions, active
artifact.guide_source.ingest, and active fixed-service guide binding/read;
the remaining rows cover canonical
submission.create, and 23 review actions. An action becomes active only when
its feature owner has merged the canonical resource composer, guards, surface or
command declaration, behavior tests, and transaction-local revalidation where
required, and its dedicated AUTH activation custodian has integrated the exact
evaluator and changed availability. Both halves are mandatory; registry or
feature presence alone never grants authority.
WS-XINT-003-02C registers the four approved REV recovery/lifecycle actions as
planned and unavailable. artifact.review_evidence.binding.create is also
registered but planned and unavailable. Registration adds no evaluator, route,
job, principal row, or lifecycle authority; activation remains blocked until
complete feature-owned typed and transaction manifests exist.
AUTH-07B activates actor.profile.read_self and actor.profile.update_self.
AUTH-08 activates exactly seven administrative actions through migration
0022; all other registered actions remain planned.
AUTH-09A registers these exact planned actions in the v0.1 baseline:
| ActionId | PermissionId | Activation owner |
|---|---|---|
actor.profile.read |
actor.profile.read_any |
WS-AUTH-001-09C |
actor.profile.suspend |
actor.profile.suspend |
WS-AUTH-001-09D-A |
actor.profile.reactivate |
actor.profile.reactivate |
WS-AUTH-001-09D-A |
actor.profile.deactivate |
actor.profile.deactivate |
WS-AUTH-001-09D-A |
actor.identity_link.read |
actor.identity_link.read |
WS-AUTH-001-09C |
actor.identity_link.revoke |
actor.identity_link.revoke |
WS-AUTH-001-09D-B |
actor.identity_link.reactivate |
actor.identity_link.reactivate |
WS-AUTH-001-09D-B |
actor.service.provision |
actor.service.provision |
WS-AUTH-001-09B |
AUTH-09B activates only actor.service.provision through the controlled route
described below. AUTH-09C activates only the two bounded actor-registry reads.
AUTH-09D-A profile lifecycle activation is complemented by AUTH-09D-B, which
activates exact identity-link revoke and reactivate behavior and their
route, typed resource context, evaluator, guards, transaction proof, and
availability change. AUTH-09A supplies none of those runtime paths.
The submission/review dependency matrix is closed. AUTH-07A registers only the
stable planned fields shown here; resource facts, candidates, guards, and
hidden behavior remain with REV. WS-AUTH-001-REV-CUSTODY has replaced only
the 19 historical REV owner values with the exact AUTH activation custodians
below. Mappings and planned availability are unchanged, and the custodian
labels grant no reviewer, Operator, or service authority. Before any review
action activates, its dedicated AUTH custodian must integrate the complete
feature proof according to the
activation-custody contract
and the canonical review custody contract below.
The AUTH-REV table immediately below is retained as runtime catalogue history.
For all future work, the canonical planning custody, principals, resource
families, fixed identities, and exact XINT-003 waves are in
engineering/review_authorization_action_custody.md.
Chunk 01 changes no runtime owner or availability.
| AUTH activation custodian | Exact planned ActionIds |
|---|---|
WS-AUTH-001-REV-05 |
review.queue.read, review.queue.inspect |
WS-AUTH-001-REV-06 |
review.claim, review.release, review.decline_preference, review.preference_expiry.run, review.lease_expiry.run |
WS-AUTH-001-REV-07 |
review.context.read, review.chain.read, review.finding_evidence.ingest |
WS-AUTH-001-REV-08 |
review.decision |
WS-AUTH-001-REV-09A |
review.finding_response_evidence.ingest |
WS-AUTH-001-REV-11 |
review.lease.force_release, review.queue.routing.override, review.queue.routing.correct, review.queue.close, review.reconcile.run |
WS-AUTH-001-REV-12 |
review.artifact_reference.reconcile, review.projection.rebuild |
WS-XINT-003-08A |
review.revision_context.repair, review.revision_obligation.close, review.revision_context.legacy_close |
WS-XINT-003-08B |
review.lifecycle.activation.manage |
The first seven rows preserve the trusted pre-WS-XINT-003-02C custody baseline.
Those 19 actions remain planned and unavailable, while 02C registers the four approved REV
recovery/lifecycle actions under XINT-003-08A/08B custody. The delivery path is
front-loaded WS-XINT-003-02C unavailable catalogue/principal/matrix readiness
followed by WS-XINT-003-02D closed PREP/read contract readiness. Neither wave
implements REV behavior or activates a lifecycle action; later XINT activation
uses the canonical custody map and exact merged REV proof.
| ActionId | PermissionId | AUTH activation custodian |
|---|---|---|
submission.create |
submission.create |
WS-AUTH-001-14 |
review.queue.read |
review.queue.read |
WS-AUTH-001-REV-05 |
review.queue.inspect |
review.queue.inspect |
WS-AUTH-001-REV-05 |
review.claim |
review.claim |
WS-AUTH-001-REV-06 |
review.release |
review.release |
WS-AUTH-001-REV-06 |
review.decline_preference |
review.decline_preference |
WS-AUTH-001-REV-06 |
review.preference_expiry.run |
operations.timer.run |
WS-AUTH-001-REV-06 |
review.lease_expiry.run |
operations.timer.run |
WS-AUTH-001-REV-06 |
review.context.read |
submission.read_for_review |
WS-AUTH-001-REV-07 |
review.chain.read |
review.chain.read |
WS-AUTH-001-REV-07 |
review.finding_evidence.ingest |
review.decision |
WS-AUTH-001-REV-07 |
review.decision |
review.decision |
WS-AUTH-001-REV-08 |
review.finding_response_evidence.ingest |
submission.create |
WS-AUTH-001-REV-09A |
review.lease.force_release |
review.lease.force_release |
WS-AUTH-001-REV-11 |
review.queue.routing.override |
review.queue.override |
WS-AUTH-001-REV-11 |
review.queue.routing.correct |
review.queue.override |
WS-AUTH-001-REV-11 |
review.queue.close |
review.queue.override |
WS-AUTH-001-REV-11 |
review.reconcile.run |
operations.reconcile.run |
WS-AUTH-001-REV-11 |
review.artifact_reference.reconcile |
operations.reconcile.run |
WS-AUTH-001-REV-12 |
review.projection.rebuild |
operations.projection.rebuild |
WS-AUTH-001-REV-12 |
review.revision_context.repair |
project.task.manage |
WS-XINT-003-08A |
review.revision_obligation.close |
project.task.manage |
WS-XINT-003-08A |
review.revision_context.legacy_close |
operations.reconcile.run |
WS-XINT-003-08A |
review.lifecycle.activation.manage |
operations.reconcile.run |
WS-XINT-003-08B |
WS-XINT-003-02D publishes the complete inert REV authorization manifest in
app.modules.authorization.review_contracts. Every registered review.*
ActionId maps to one strict typed resource family or, for the two unapproved
evidence-upload actions, to explicit unsupported_future_intent. Shared
families retain exact action discriminators; fixed-service contracts bind the
exact service identity and server-derived execution mode. In particular, the
two services sharing review.reconcile.run cannot exchange modes.
These frozen scalar models carry no ORM rows, bytes, provider values, callback,
or prepared handle. Publishing them changes no action availability and adds no
evaluator. Reads continue through request-scoped authorization. Mutations and
service commands later use the existing opaque, process-local, transaction-
bound PreparedAuthorizationHandle; REV locks and composes canonical facts,
while the exact activation wave installs the corresponding AUTH evaluator.
XINT-002 packet, evidence-binding, and revision-submission actions are external
handoff references only and are not redefined by this manifest.
Initial and revision submission use the same submission.create action,
permission, and route. Revision preparation is an internal participant and
lifecycle guard of that command; no submission.revise or revision-prepare
action exists. Finding and finding-response evidence intake are distinct
protected commands mapped to existing permissions. The only new permission is
review.queue.override.
Artifact verification recovery remains the existing
artifact.verification_job.retry action through the ART-owned
ArtifactOperatorRecoveryPort; no artifact_recovery.request permission is
registered. Shared outbox dispatch/retry remains owned by the shared-outbox
subsystem and is not represented as a REV-owned projection action.
The v0.1 baseline is availability-neutral for this surface. PostgreSQL enforces the closed
ActionId set, authorization-decision event shape, exact ActionId-to-PermissionId
mapping, and the requirement that every post-0018 permission carry a mapped
action. Typed catalogue validation separately rejects allowed evidence until the
dedicated AUTH activation custodian changes an action from planned to active
after merged feature behavior proof.
The paired artifact hidden-behavior matrix is closed:
| Resource-owning WS-ART chunk | Hidden actions/resources implemented by that chunk |
|---|---|
WS-ART-001-02D |
Operator binding/replica/receipt/verification-job/recovery-attempt/audit reads; the operations-domain operations.artifact_storage_admission.read action mapped to operations.status.read; verification retry; artifact.verification.execute; artifact.pending_work.scan; and artifact.put_attempt.resolve |
WS-ART-001-03 |
Hidden guide behavior for artifact.guide_source.ingest -> artifact.guide_source.ingest, artifact.guide_source.read -> artifact.guide_source.read; AUTH activation custody is split between WS-XINT-002-04A and 04B below |
WS-ART-001-04A historical baseline |
the former multi-step upload authority had no route/command and is deleted from the live catalogue by WS-XINT-002-01 without compatibility aliases |
WS-ART-001-04A1 through 04C2 |
one hidden artifact.submission_bundle.prepare surface mapped to submission.create; 04B1-04B3 implement the sole catalogue/materialization/evidence path and XINT-002-06A activates its fixed pre-submit materializer before 04C1; WS-ARCH-001-02G activates hidden contributor preparation and 02H activates hidden consumption/binding on the completed 02A-02F owner foundation; the public Submission cutover remains 02I work; POL-07B connects the internal checker phase service and removes the standalone JSON precheck |
WS-ART-001-04B2 and 04B3 |
hidden artifact.pre_submit.checker_input.materialize resource/guard usage mapped to artifact.checker_input.materialize; 04B2 owns exact sealed materialization and 04B3 consumes it in the complete effective plan |
WS-ART-001-05 |
artifact.submission.binding.create mapped to artifact.binding.create |
WS-ART-001-06A |
artifact.post_submit.checker_input.materialize mapped to artifact.checker_input.materialize |
WS-ART-001-06B |
artifact.checker_output.write mapped to artifact.checker_output.write; artifact.checker_output.binding.create mapped to artifact.binding.create, both using the checker-run resource |
WS-XINT-002-01 deletes the former multi-step authority and registers planned
artifact.submission_bundle.prepare -> submission.create. No ART implementation
may execute that ActionId while it remains planned. The mandatory order is
ART-04A1 -> 04A2 -> 04A3 -> PLAN4 -> PLAN5 -> ART-04B1 -> ART-04B2 ->
ART-04B3 -> XINT-002-06A -> ART-04C1 -> ART-04C2 -> WS-ARCH-001-02A -> 02B -> 02C ->
02D -> 02E -> 02F -> 02G. This ensures fixed-service pre-submit
materialization and the complete hidden public-capability/transaction path are
active before contributor preparation can become live. XINT-002-05A/05B are
superseded historical records.
WS-XINT-002-04A activates only artifact.guide_source.ingest. The existing
permission belongs only to the Project Manager role and is evaluated through an
active covered grant: system-scoped or exact-project. Its prepared capability locks the
actor, exact identity link, and matched grant before byte intake; final
consumption binds the ART-locked project, draft guide, snapshot, item,
operation/request digests, and server-computed byte facts. WS-XINT-002-04B
separately activates guide-source read and binding creation for their exact
fixed service identities. Both use opaque transaction-bound PREP handles bound
to the complete verified-content and setup-generation facts; neither authority
is inherited from the Project Manager uploader.
Every row requires AUTH-07A's registry and AUTH-07B's kernel first. A row with an Operator principal also requires its AUTH-08 grant definition; a row with a fixed service principal also requires AUTH-09A's static matrix, AUTH-09B's provisioned service ActorProfile and ActorIdentityLink, and AUTH-09E fixed service runtime admission. After the named ART behavior merges, the dedicated AUTH custodian integrates and activates the exact evaluator. Feature code receives centralized decisions; it never queries grants, constructs permission identifiers dynamically, or changes availability.
The following table is the single source of truth for artifact ActionId-to-
PermissionId mappings, principal/resource facts, and ART hidden-behavior
ownership. AUTH-07A registered each row's stable ActionId, approved
PermissionId, historical owner value, and initial planned availability.
WS-AUTH-001-ART-CUSTODY has now replaced only those historical owner values
with the exact AUTH activation custodians below; mappings and ART
hidden-behavior ownership are unchanged, while reviewed activation chunks may
change availability. Its principal-class and
canonical-resource columns are not AUTH
registry fields and are not executable authority; the owning WS-ART chunk adopts
them with its hidden canonical resource composer, guards, surface declaration,
and behavior tests. This specification is the canonical activation-custody
source; the former planning handoff is historical Git evidence only. A mapping
is not a permission alias.
| AUTH activation custodian | Exact ActionIds and current availability |
|---|---|
WS-AUTH-001-ART-02D-INTERNAL |
Active: artifact.verification.execute, artifact.pending_work.scan, artifact.put_attempt.resolve |
WS-AUTH-001-ART-02D-OPERATOR |
artifact.binding.read, artifact.replica.read, artifact.receipt.read, artifact.verification_job.read, artifact.verification_job.retry, artifact.recovery_attempt.read, artifact.audit.read, operations.artifact_storage_admission.read |
WS-XINT-002-04A |
Active: artifact.guide_source.ingest |
WS-XINT-002-04B |
Active: artifact.guide_source.read |
WS-XINT-002-05A |
Active artifact.submission_bundle.prepare; registry custody retained while replacement implementation chunk WS-ARCH-001-02G supplies the executable PREP boundary |
WS-XINT-002-06A |
artifact.pre_submit.checker_input.materialize |
WS-AUTH-001-ART-05 |
artifact.submission.binding.create; activated by replacement implementation chunk WS-ARCH-001-02H for only the fixed artifact-binding service |
WS-XINT-002-06B |
artifact.post_submit.checker_input.materialize, artifact.checker_output.write, artifact.checker_output.binding.create |
WS-XINT-002-07A |
artifact.review_packet.materialize only |
| Future REV-owned activation, not approved for v0.1 | artifact.review_evidence.binding.create remains planned/unavailable |
The table retains planning-custody labels; these are not uniformly the typed
runtime ActionOwner values or the current implementation boundaries.
In particular, the XINT-06B grouping corresponds to runtime
WS-AUTH-001-ART-06A for post-submit materialization and
WS-AUTH-001-ART-06B for checker-output write/binding. The current replacement
activation contract is ARCH-04D2. Exact post-submit input, execute and finalize
authority is delivered; checker-output write/bind remains planned because the
current catalogue produces no output files. ARCH-04E1A route-neutral source
facts and accepted-effects contracts are delivered; REV-04C supplies the hidden
FinalAcceptance/TASK/CON participant without an action, handler, current pointer
or authorized runtime composition. This does not reopen XINT-06B as a parallel implementation lane. Likewise ARCH-02G/02H
are replacement implementation boundaries, not automatic registry renames.
Read exact runtime ownership from the typed catalogue. No planning-only
change may promote or reassign an action.
The approved v0.1 review flow has a reviewer decision plus note/findings bound to the reviewed Submission. It does not include a reviewer-uploaded artifact. Therefore 07A activates packet materialization only; evidence binding remains planned and unavailable unless a later REV-owned intent explicitly approves it.
The OPERATOR suffix names future activation custody only; it creates no
Operator grant or entitlement. WS-XINT-002-03 activates the three internal
service actions, WS-XINT-002-04A activates guide-source ingest, and
WS-XINT-002-04B activates the two fixed-service guide binding/read actions, and
WS-ARCH-001-02G activates contributor bundle preparation. WS-ARCH-001-02H
activates submission binding for the fixed artifact-binding service; the other
14 ART actions remain planned and unavailable.
The v0.1 baseline admits the exact privacy-bounded ART resource-context digest
in append-only authorization decision facts; it adds no table or column.
artifact.verification_job.retry requires its own later evaluator, guards, and
independent activation proof; read/status proof cannot activate retry. The
historical ART transfer added no migration; WS-XINT-002-01 reconciles the
closed catalogue in the v0.1 baseline. The separately started REV custody
transfer is also complete: all 19 REV rows now name exact AUTH custodians,
remain planned and unavailable, and add no migration.
| ActionId | PermissionId | Principal class | Canonical resource | Resource-owning WS-ART chunk |
|---|---|---|---|---|
artifact.binding.read |
artifact.binding.read |
Operator | artifact binding | 02D |
artifact.replica.read |
artifact.replica.read |
Operator | artifact replica | 02D |
artifact.receipt.read |
artifact.receipt.read |
Operator | artifact receipt | 02D |
artifact.verification_job.read |
artifact.verification_job.read |
Operator | verification job | 02D |
artifact.verification_job.retry |
artifact.verification_job.retry |
Operator | exhausted verification job | 02D |
artifact.recovery_attempt.read |
artifact.recovery_attempt.read |
Operator | recovery attempt | 02D |
artifact.audit.read |
artifact.audit.read |
Operator | artifact audit scope | 02D |
operations.artifact_storage_admission.read |
operations.status.read |
Operator | deployment artifact-storage namespace | 02D |
artifact.guide_source.ingest |
artifact.guide_source.ingest |
exact covered Project Manager | guide-source snapshot item | 03 |
artifact.guide_source.read |
artifact.guide_source.read |
fixed guide-reader service | exact committed document version and fenced compilation attempt | 03 |
artifact.submission_bundle.prepare |
submission.create |
assigned contributor | exact task/admission context | 04C2 |
artifact.submission.binding.create |
artifact.binding.create |
fixed binding service | submission | 05 |
artifact.checker_output.binding.create |
artifact.binding.create |
fixed binding service | checker run | 06B |
artifact.verification.execute |
artifact.verification.execute |
fixed verifier service | verification job | 02D |
artifact.pending_work.scan |
artifact.pending_work.scan |
fixed scheduler service | system pending-work scope | 02D |
artifact.put_attempt.resolve |
artifact.put_attempt.resolve |
fixed put-resolver service | put attempt | 02D |
artifact.pre_submit.checker_input.materialize |
artifact.checker_input.materialize |
fixed materializer service | exact task, assignment, project/guide/snapshot and locked policy lineage plus plan/catalogue/archive/semantic-manifest identities and current process-local prepared generation; no scratch path/handle is serialized | 04B2/04B3 + XINT-002-06A |
artifact.post_submit.checker_input.materialize |
artifact.checker_input.materialize |
fixed materializer service | checker run and immutable bindings | 06A |
artifact.checker_output.write |
artifact.checker_output.write |
fixed checker-output service | checker run | 06B |
artifact.review_packet.materialize |
artifact.review_packet.materialize |
fixed materializer service | exact active lease and Submission packet | 07A |
artifact.review_evidence.binding.create |
artifact.binding.create |
fixed binding service | future REV-owned evidence slot; no approved v0.1 activation | future |
The resource-owning chunk cells above identify ART hidden-behavior custody; they
are distinct from the AUTH activation-custodian table and runtime
ActionOwner. An approved XINT activation wave may take exact runtime owner
custody for its one action; it does not change ART product-behavior ownership.
The fixed internal service identities and their complete action sets are also closed:
| Service identity | Allowed actions |
|---|---|
workstream.artifact.verifier |
artifact.verification.execute |
workstream.artifact.put_resolver |
artifact.put_attempt.resolve |
workstream.artifact.scheduler |
artifact.pending_work.scan |
workstream.artifact.binding |
active/activatable v0.1: artifact.submission.binding.create, artifact.checker_output.binding.create; planned/unavailable future: artifact.review_evidence.binding.create |
workstream.artifact.guide_reader |
artifact.guide_source.read |
workstream.artifact.materializer |
artifact.pre_submit.checker_input.materialize, artifact.post_submit.checker_input.materialize, artifact.review_packet.materialize |
workstream.artifact.checker_output |
artifact.checker_output.write |
workstream.project.setup |
project.guide_compilation.request_automatic, project.guide_compilation.execute, project.guide_sufficiency.run, project.submission_artifact_policy.derive, project.post_submit_checker_policy.derive, project.setup_run.update |
workstream.review.preference_expiry |
review.preference_expiry.run |
workstream.review.lease_expiry |
review.lease_expiry.run |
workstream.review.authority_invalidation_reconciliation |
review.reconcile.run |
workstream.review.reconciliation |
review.reconcile.run |
workstream.review.artifact_reference_reconciliation |
review.artifact_reference.reconcile |
workstream.review.projection |
review.projection.rebuild |
workstream.outbox.dispatcher |
active shared mechanics only: outbox.dispatch |
workstream.task.assignment_reconciler |
active hidden assignment effect only: task.assignment.authority_reconcile |
workstream.compensation.adapter |
target-only; no action membership |
The hidden 04B2 prepared resource first locks fixed-service authority using
task, assignment, project, effective
submission-artifact-policy ID, pre-submit checker-policy ID, process-local
prepared generation, plan hash, catalogue-manifest hash, archive SHA-256/byte
count, and storage scheme before ZIP inspection. The fixed materializer then
consumes the same opaque handle against those facts plus the server-computed
semantic-manifest hash before workspace reservation or checker execution.
WS-XINT-002-06A is the catalogue owner and activates the
action after merged ART-04B3; ART does not activate it. The ART-04C1 caller
must lock and revalidate the exact active assignment before preparing these
facts because TaskAssignment uses a new immutable ID for replacement rather
than a separate generation counter.
workstream.project.setup was the eighth fixed identity when AUTH-12B merged;
02C expanded that registry to fourteen identities. The current registry has
seventeen identities after the target-only compensation adapter, shared outbox
dispatcher and task assignment reconciler registrations. AUTH-12E activates
project.guide_sufficiency.run, AUTH-12F3 activates policy derivation, and
AUTH-12I activates exact unified compilation execution. AUTH-12B2 activates
exact setup finalization; AUTH-12G activates
project.post_submit_checker_policy.derive for the same fixed setup identity. All six REV rows remain unavailable.
Registration makes the
identity selectable by the existing controlled provisioning route but creates
no ActorProfile, ActorIdentityLink, role, grant, or executable authority by
itself; the v0.1 baseline only expands the closed database
identity constraint.
AUTH-12J reuses the active sufficiency-run and artifact-policy-derive rows for
two purpose-specific deterministic projection contexts. Only
workstream.project.setup may prepare them. Their authority evidence uses the
exact projection resource type, deterministic operation ID, project, actor,
action, permission, and the public projection authority digest. The legacy
AUTH-12E/12F3 mutation contexts remain separate and cannot exchange prepared
handles with these projection contexts. AUTH-12J adds no action or live route.
AUTH-09B lets a system Access Administrator bind an exact configured-issuer
subject with no leading or trailing whitespace to one of these fixed identities
through POST /api/v1/service-actors. Accepted subject bytes are preserved
without normalization.
It creates the service ActorProfile and ActorIdentityLink, but creates no role,
grant, assignment, or executable service authority. A newly provisioned service
profile has null last_seen_at, and its link has null last_verified_at until
AUTH-09E verifies and admits that exact service token. The service-action matrix
is typed code, not a database assignment or grant table. Its rows remain inert
while their actions are planned. After the ART execution behavior merges, the
dedicated AUTH activation custodian integrates the evaluator and changes only
the exact action to active. Composition startup proves registry, service actor,
matrix row, action, and PermissionId parity and fails closed on missing or extra
matrix membership. Negative authorization tests prove each service identity is
denied every fixed-service action outside its row. Human authorization remains
attached to the initiating product command; an internal service identity never
inherits a human grant or role.
Adding a permission requires a specification/ADR update and human approval. Routers cannot invent identifiers or evaluate grant unions.
outbox.dispatch and task.assignment.authority_reconcile are active for their
separate fixed services and included in current catalogue counts. The dispatcher
authorizes shared delivery mechanics; the reconciler authorizes the hidden
assignment effect. Checker execute/finalize authority is implemented by ARCH-04D2. AUTH-19A
registers task.post_submit.route and its fixed identity as planned and unavailable;
registration is included in the catalogue counts but grants no authority. The named implementation boundaries must register
typed parity, prove hidden behavior and activate only their exact manifests;
a planning document does not grant a service permission.
| ActionId / PermissionId | Sole fixed identity | Exact target and guards | Current activation custodian |
|---|---|---|---|
outbox.dispatch |
workstream.outbox.dispatcher |
Event/claim generation/lease and exact phase; fresh authority for claim, invoke and finalize; no feature authority | AUTH-OUTBOX-02 authority/phase custody and Celery composition complete; feature handlers remain separate |
task.assignment.authority_reconcile |
workstream.task.assignment_reconciler |
Committed exact AUTH invalidation event, project/actor/grant-or-link, active pre-submit assignment; no wrong-role or submitted-history mutation | ARCH-03B9 hidden handler/fence and ARCH-03C1 real feature authority/decision receipts complete; ARCH-03C2 atomic producer wiring and registration |
checker.post_submit.execute |
workstream.checker.post_submit |
Immutable Submission/request/generation, locked compiled policy, attempt and admitted service; exact pre-I/O authority | Implemented by ARCH-04C/04D2; no dispatcher registration |
checker.post_submit.finalize |
workstream.checker.post_submit |
Exact execution request/fence, accepted result digest, retained material and original execute receipt; fresh post-I/O authority and atomic evidence; current outputs are empty | Implemented by ARCH-04C/04D2; no dispatcher registration |
task.post_submit.route |
workstream.task.post_submit_router |
Committed completion event/claim, exact current CHECKER result/fence, immutable Submission, locked ReviewPolicy and TASK pre-review state; true permits only the TASK manifest transition to review_pending, false/pass binds exact accepted TASK effects for the shared FinalAcceptance consequence; never a human review decision or generic CON write |
AUTH-19A inert source/request commitments, 04E1B-A request facts, 04E2-A strict preparation and the REV-04C hidden FinalAcceptance/TASK/CON participant are delivered. Planned denial still prevents a handle, allow or receipt. 04E1B-B supplies hidden handlers/currentness race proof; 04E2-B requires the exact AUTH receipt on the same strict input, adds database/audit/outbox closure and activates the first genuine atomic consequence; 04E3 wires live composition |
Each action maps to the identically named permission in this table and only its singleton fixed-service row. Humans, dispatchers and unrelated services cannot borrow another row. Existing ART materializer/output identities retain their separate permissions and allow evidence. No prepared handle crosses a commit, I/O, lease wait or message boundary.
Human task actions and existing permission mappings are enumerated in
the ARCH-03C manifest.
In particular, task.start uses existing task.claim entitlement plus exact
own-assignment guards; Operator recovery remains the distinct
operations.task.start_override permission with a system-scoped human grant.
Separate management/operational/audit projections preserve their respective
permissions rather than switching one action's mapping based on token roles.
ARCH-03C3 activates project.task.create, project.task.screen and
project.task.release under existing project.task.manage; no new permission or
broader Project Manager permission set is introduced. ARCH-03C4 activates:
task.queue.read under task.queue.read for exact-project Submitters;
project.task.queue.read under project.task.manage for covering Project Managers;
and operations.task.queue.read under operations.status.read for system Operators.
All three lock the live actor profile/link, matched grant and exact Project in
that order, then read TASK without row locks. Contributor discovery requires an
active project. Signed cursors bind action/project/limit/order, while decision
evidence separately binds the hash of the presented cursor. Authority, projection,
JSON validation and the successful decision commit share one transaction.
ARCH-03C5 activates detail/requirements and ARCH-03C6 activates the three
locked-context actions. ARCH-03C7 activates bounded task-history reads under
covered Audit Authority; no other role sharing audit.read receives this action.
The AUTH-12F4 contract activates exact complete-compilation review-package read and correction under existing guide-management and compilation-request permissions. Only a current human Project Manager grant on the exact project qualifies; status-only diagnostic authority cannot expose a complete proposal.
Proposal PREP locks the current identity and exact-project manager grant before PROJECTS locks the proposal. Complete read, approval and correction share that path; services and system-scoped management grants cannot consume it. AUTH binds its audit correlation to the POL operation ID while preserving the authenticated transport request ID. Exact replay checks fresh authority and the retained allowed decision, including operation correlation and the canonical business digest, without requiring the original transport request or writing another allow. Product transactions and immutable output ownership remain in PROJECTS. No public proposal endpoint is enabled by this authorization chunk.
The permission catalog is consumed through a closed, typed action registry.
Each active action definition has its own stable ActionId and binds one
approved PermissionId to:
- one canonical authorization target resource type;
- the rule for resolving that target, including the existing parent or
systemtarget used when the requested operation creates a new resource; - the allowed human or service principal class and authority-candidate sources;
- registered global, resource, ownership, assignment, separation-of-duties, and lifecycle guards; and
- the closed, typed resource facts required by each guard; and
- whether authority must be revalidated inside the committing transaction.
Multiple closed actions may map to one approved broad permission while having
different canonical targets and guards. For example, create and update actions
may share an approved management permission but target an existing parent and
an existing child respectively. Routes declare ActionId, never an arbitrary
permission/target pair. Splitting a broad permission into new permission tokens
still requires the separate approval and migration rule above.
The registry does not own domain persistence or state transitions. Feature
repositories return their domain records, and feature application services or
feature-owned loaders compose the bounded ResourceContext. Loader
implementations may be registered at the application composition root, but the
authorization module must not duplicate feature queries or import a parallel
resource repository. Resource contexts use closed per-resource variants rather
than a free-form attribute bag. Registration rejects undeclared facts, and
authorization fails closed when a required fact is absent or has the wrong
type. Request bodies, query values, and path combinations remain untrusted
hints; canonical parent, project, owner, assignment, and state facts come from
PostgreSQL.
Each protected FastAPI route and asynchronous command declares one primary registered action. That declaration selects the authorization target and mandatory guards; it does not replace domain invariants or permit a route-local secondary policy. Internal jobs declare fixed Workstream service authority and never serialize a human bearer token as executable authority. Collection actions authorize and filter against their canonical parent scope before counts, cursors, facets, or distinct values are computed.
Registration and completeness are staged with the approved chunk map. Chunk
07A introduces the identifiers and planned registry; 07B introduces the kernel
and first active self-actions. Reserved action metadata contains only the
stable ActionId, approved PermissionId, owning specification/chunk, and
planned availability; it is not executable and does not predefine a
foreign-domain target, facts, or guards. Every route-owning chunk from 07B
through 15 supplies hidden behavior, feature-owned resource composition,
surface declarations, and behavior proof while its action remains planned and
fails closed. Only the action's dedicated AUTH activation custodian may promote
it to active after integrating the evaluator and verifying that proof. Each
feature chunk generates a manifest-delta proof for every surface it prepares;
the matching AUTH activation chunk records the availability delta. Chunk 16
aggregates and verifies the complete route/command manifest rather than first
discovering missing declarations there.
Resources and transitions owned by WS-REV, WS-CON, or the artifact-storage
specification are not invented by AUTH; their owning specification must first
approve the resource facts and operation before a corresponding permission is
added under the approval rule above.
For every protected operation:
- Verify the external token through the existing verifier boundary.
- Resolve the canonical identity link and actor profile without preempting the action's lifecycle guards.
- Build the closed request-scoped
HumanAuthorizationContext | ServiceAuthorizationContextunion without token-role authority. Only the service variant carries a required, closedservice_identity. - Load the canonical resource through its owning repository/service.
- Compose
ResourceContextin the application service. - Load active candidate grants using database time.
- Expand only registered permission candidates compatible with grant scope.
- Apply actor, exact-project, ownership, assignment, separation-of-duties, task-ban, and lifecycle guards.
- For actor-self reads/updates and sensitive mutations, revalidate current identity or authority inside the same transaction immediately before acting.
- Return allow or a stable denial code without leaking hidden resources.
Authorization decisions are request-scoped and are not cached across requests. Each decision carries a bounded SHA-256 digest of its complete typed resource context so feature code cannot reuse it with substituted role, scope, target, or replay facts. List filtering occurs before counts and pagination cursors.
Context-type dispatch occurs before candidate lookup. A service context never
enters actor-self, administrative-grant, project-grant, contributor, or human
rate-control paths. AUTH checks exact ActionId membership in the fixed
identity's static matrix row before checking availability; a different row
denies even when both actions share one PermissionId. An own-row action still
denies while its availability is planned.
Sensitive mutations use the prepared protocol instead of evaluating final authority against unlocked feature facts:
AUTH locks AuthorityControl first when final-admin safety applies
-> AUTH orders principals by ActorProfile ID
-> human: ActorProfile -> exact ActorIdentityLink -> exact matched grant
-> service: ActorProfile -> exact ActorIdentityLink -> code-owned validations
-> AUTH creates one internal non-Pydantic PreparedAuthorizationHandle bound to
session, action, actor reference, idempotency key, and request digest
-> feature locks its canonical rows and recomposes final typed facts
-> AUTH consumes the handle, evaluates once, and stages decision evidence
-> feature participants flush
-> route or service command commits once
The PREP foundation issues handles for actor.profile.update_self, the eight
active AdminRoleGrant-backed administrative mutations, the three active fixed
ART foundation service actions, Project Manager
artifact.guide_source.ingest, and the fixed-service
artifact.guide_source.read
action, contributor artifact.submission_bundle.prepare, hidden human
submission.create, and fixed-service artifact.submission.binding.create.
Checker, review, generic artifact-read, and the public Submission cutover remain
planned and issue no handle.
ARCH-04E1B-B6 retains the exact creation and binding decision IDs in their owner
receipts. Fresh PREP authority validates those immutable events on replay,
including exact actor/service, action, permission, project, resource and canonical
context digest. The retained event keeps its original request/correlation IDs and
grant provenance; fresh transport IDs do not create another allow. Missing or
inconsistent receipts make replay unavailable. No public route is added.
Actor-self preparation locks the exact caller
profile and then its exact identity link. Administrative preparation locks
AuthorityControl(id=1), the exact request profile, exact request identity
link, and one deterministic effective AdminRoleGrant. The caller supplies an
independent expected ActionId when consuming the handle; AUTH checks it before
consumption, then checks the canonical request digest, idempotency UUID, exact
root transaction, and final actor-self/system/exact-project scope. A matching
attempt consumes the handle permanently before evaluation or evidence staging.
Cancellation and failures propagate to caller-owned rollback and never restore
the capability.
Preparation-time planned fixed-service denial has no final resource context, so
it returns the bounded action_unavailable outcome without staging evidence.
An exact-consume denial stages its decision only in the caller transaction; the
required rollback removes that event with participant state. PREP never
restages or commits denial evidence separately.
WS-XINT-002-02 closes the process-local PREP-to-ART operation interface without
activating an action. Durable ART mutation requests carry the opaque
PreparedAuthorizationHandle, never a raw AuthorizationContext; each typed
method fixes its expected action and accepts no caller-selected action or
generic facts map. The handle is non-Pydantic and cannot enter route schemas,
outbox/Celery payloads, provider interfaces, or serialized contracts. Exact
feature contexts and session/root-bound composer proofs remain owned by the
later evidence-backed activation chunks.
PREP's neutral PostgreSQL participant remains a test proof that final facts, one
decision event, participant work, and caller commit or rollback share the same
transaction. WS-XINT-002-03 adds the first active feature consumer: exact typed
prepared capabilities for the ART verifier, pending-work scanner, and
put-attempt resolver. Fixed services are locked and refreshed before either an
active-action decision or a still-planned action_unavailable denial;
still-planned actions issue no handle. For ART adapter calls only, any exact
denial is retained across the caller rollback and restaged through AUTH's
bounded public operation in a clean AUTH-only transaction. General PREP callers
do not restage rolled-back denial evidence. ProjectRoleGrant does not exist in
PREP; AUTH-10 must add its exact row lock, evaluator branch, and crossed-
revocation evidence before an exact-project product consumer can use that
authority source.
WS-XINT-002-04A adds the first active human feature consumer. Guide ingest preparation locks the caller profile, exact identity link, and one active covered Project Manager AdminRoleGrant before byte intake. ART then locks the project, draft guide, snapshot, and item and supplies operation/request digests plus server-computed digest, byte count, and media type for final consumption. The allowed decision evidence carries the matched grant/project and exact final resource-context digest in the same transaction as admission.
Service identity, static service-action matrix membership, and action availability are immutable code-owned validations after the service profile and link locks; they are not database rows or lock targets. Existing actor-self, administrative, and lifecycle mutations must use the same authority-row order before any prepared consumer ships.
AUTH-09E supplies the reusable transaction-local service-authority lock and
revalidation seam: reload and lock profile then exact link, recheck row
identity, lifecycle, immutable service identity, exact matrix membership, and
current action availability, and return refreshed typed authority without
committing. Later feature activation chunks own locked feature-row
recomposition, their exact ResourceContext, and terminal mutation proof.
The handle is single-use, nonserializable, and never a route schema or caller
input. Consumption matches the exact session, action, actor reference kind,
actor reference, idempotency key, and request digest before feature mutation.
Reuse, same-session/action cross-actor or cross-request substitution, authority
loss, evidence failure, participant failure, cancellation, or commit failure
leaves no feature mutation or partial authority evidence. Reads continue to use
request-scoped require(). AUTH never imports feature repositories, and
dependency teardown never commits shared feature work.
Crossed PostgreSQL tests cover PREP against link revocation, actor suspension or
deactivation, exact grant revocation, and final-admin mutation.
For the two active self actions, the default human authority source is
actor_self; token roles and client-supplied permissions never enter the
context. Self-read requires an active link and an active actor; suspension
denies self-read as well as self-update.
Self-update through ordinary request authorization retains its existing
revalidation behavior; prepared self-update locks the exact profile followed by
its exact link,
rebuilds current context inside the caller transaction, and requires an active
actor plus a non-empty subset of display_name and contact_email. Revoked
links, deactivated actors, and suspended updates deny in that order. Planned
and unknown actions deny as permission_not_granted at public boundaries, and
a system resource grants no implicit authority.
AuthorizationService.require(action_id, typed_resource_context) has exactly
those two method arguments because the request context, caller-owned
AsyncSession, and actor-self revalidator are constructor-bound. The service
stages one bounded decision event and never commits. A denied mutation rolls
back first, then restages the unchanged denial in a clean transaction so no
business mutation can share a denial commit.
AuthorizationDecision carries the stable ActionId in addition to permission,
resource, scope, matched authority, and denial information. The action identifier
is included in bounded logs/metrics and every action-based allowed or denied
authority event emitted by AUTH-07B or a later chunk. AUTH-07A adds nullable
historical storage and exact typed/SQL registry parity; legacy rows remain null,
while new AUTH-07B-or-later action-based decision events must contain a
registered identifier. A
new action identifier requires the same approved typed/PostgreSQL registry and
migration treatment as a permission.
- An actor cannot grant or revoke their own authority through an administrative grant operation.
- A submitter cannot act as the sole reviewer of their own work.
- Project Manager authority is limited to its grant scope. A system-scoped Project Manager covers all projects but remains subject to resource and lifecycle guards; an exact-project grant covers only that project. Only a system-scoped Project Manager may create a project because no project scope exists before creation.
- Administrative roles alone cannot claim contributor work, submit, or review.
- Operator recovery is distinct from Project Manager management.
operations.task.start_override,operations.submission_gate.repair, andoperations.checker.retryrequire an exact reason, canonical resource scope, matched permission/grant, and append-only evidence.- Recovery cannot erase checker evidence, mutate immutable submissions, create a human review decision, rewrite contribution history, or bypass compensation guards.
review.lease.force_releaseis governed by WS-REV-001.
Internal system workers use fixed Workstream system principals with explicit registered system permissions. They never receive fabricated human grants. Serialized requester identity is provenance only. Actor-attributed jobs reload current actor/link/grant state before committing.
Fixed service callers use a dedicated AUTH service-admission path. It resolves
the verified service subject to one active identity link and service
ActorProfile, validates the immutable service_identity, and selects only that
identity's exact static ActionId row. It never enters human provisioning or
human grant evaluation. Feature actions remain unavailable until their owning
feature supplies canonical resource facts, guards, hidden behavior, and proof
and AUTH separately activates them.
Exact active resolution may stage monotonic profile/link observation timestamps in the caller-owned request transaction. Admission denial stages no observations. Planned-action denial, cancellation, decision-evidence failure, or other request failure rolls staged observations back; bounded denial evidence is restaged only from a clean transaction and contains no issuer, subject, bearer material, claims, scopes, provider data, or service secret.
New fixed services are added only after the owning feature publishes an exact identity-to-ActionId manifest. AUTH then owns one closed enum/constraint/matrix extension, controlled provisioning, admission reuse, and all-pairs cross-service denial. REV timer, expiry, reconciliation, projection, artifact-reference, and release-control identities are not pre-created, and no catch-all review service exists.
The first Access Administrator is created through a local management command for an existing active human. There is no public bootstrap endpoint or shared bootstrap bearer secret.
Bootstrap locks AuthorityControl(id = 1) FOR UPDATE, validates its incomplete
irreversible state and the target's active human profile and identity link, and
writes the initial grant, completed control state, and audit event atomically.
Every later or losing bootstrap attempt returns a stable audited conflict.
Bootstrap and every grant/profile/link operation that could remove the final effective Access Administrator use the same row lock and transaction-local effective count.
Suspension, deactivation, identity-link revocation, and grant revocation take
effect on the next request and on the next sensitive transaction recheck. Each
mutation writes an invalidation event atomically with state and evidence.
Profile reactivation writes the inverse effective=false -> effective=true
component invalidation. That fact describes the profile only: a revoked link,
missing grant, or unadmitted fixed service can still make the actor ineffective.
Assignment reconciliation preserves immutable work history. A revoked actor's
ordinary claimed/in-progress assignment without a retained Submission is
published atomically by ARCH-03C2 and released through the registered handler
with ARCH-03C1's exact feature authority. A needs_revision task retains a
durable revision obligation and cannot
be returned as ordinary ready work.
Project-role invalidation is exact-role-specific. Submitter revocation alone can
enter task-assignment reconciliation and persists auth13_assignment. Reviewer
revocation creates only the REV-owned review obligation and persists
rev_reviewer_obligation. Revoking any one project role leaves the
other roles and all AdminRoleGrants unchanged. Consumers verify the cause event,
grant ID, actor, project, role, and closed future-obligation token before
changing product state.
Authority-changing APIs require canonical request hashing and idempotency keys. An exact replay returns the committed result; a mismatched replay is rejected.
Canonical authority mutation requests retain a 2,048-byte serialized envelope limit except for strictly admitted project-role issuance. That operation allows 9 KiB because its existing qualification contract includes three collections of up to twenty 120-character ASCII references and twenty canonical UUID references; the largest current serialized request is 8,626 bytes. The larger budget is selected from the validated request type, never an unvalidated discriminator. All field, role, scope and availability constraints still apply. Qualification content stays in its immutable snapshot; idempotency stores the request digest and audit events use bounded projections, not the full qualification body.
Authority events are append-only and include, when applicable:
- schema/event version;
- request and correlation identifiers;
- acting and target actor references;
- registered action identifier for action-based decisions;
- matched grant and permission;
- exact project/resource reference;
- required reason;
- idempotency key;
- bounded before/after state;
- database time.
Business state, idempotency result, authority event, and invalidation event
commit in one AsyncSession transaction. Missing evidence is not backfilled
later. Administrative mutation and post-allow denial evidence derives its
request and correlation identifiers from the exact authorization decision;
feature callers cannot supply alternate evidence identifiers.
Administrative issue/revoke also recomputes the bounded reason digest before
any state or evidence write and rejects cross-wired reason text.
Canonical route families use /api/v1:
GET|PATCH /api/v1/actors/me
GET /api/v1/authorization/permissions
GET /api/v1/authorization/admin-role-definitions
GET /api/v1/actors/{actor_profile_id}
POST /api/v1/actors/{actor_profile_id}/suspend|reactivate|deactivate
GET /api/v1/actors/{actor_profile_id}/identity-links
POST /api/v1/actor-identity-links/{identity_link_id}/revoke|reactivate
POST /api/v1/service-actors
POST|GET /api/v1/admin-role-grants
GET /api/v1/actors/{actor_profile_id}/admin-role-grants
POST /api/v1/admin-role-grants/{grant_id}/revoke
POST|GET /api/v1/projects/{project_id}/role-grants
GET /api/v1/projects/{project_id}/role-grants/{grant_id}
POST /api/v1/projects/{project_id}/role-grants/{grant_id}/revoke
Exact request/response/error contracts are introduced by their owning chunks. Grant issue input may select a registered role and compatible scope, but that selection is only the requested grant; it never supplies the caller's authority.
AUTH-07B cuts existing GET|PATCH /api/v1/actors/me behavior over to the
kernel. AUTH-08 activates the two definition reads, scoped grant/history reads,
issue/revoke APIs, and local bootstrap command. AUTH-09C activates exact actor
and identity-link reads for effective system Access Administrator or Audit
Authority grants. AUTH-09D-A activates the three profile lifecycle routes for
effective system Access Administrators only. AUTH-09D-B activates exact
identity-link revoke and reactivate for the same authority. AUTH-10B activates
the concealed project-role reads, and AUTH-10C activates exact-role issue and
revoke mutations for covered Project Managers. Those mutations use
Idempotency-Key, transaction-bound PREP, immutable qualification snapshots,
canonical replay validation, and one route-owned commit. Issue requires a
different active human with an active identity link; revoke remains available
after target suspension or identity-link revocation so authority cannot become
irremovable. AUTH-11B activates GET /api/v1/projects/{project_id} and
project-scoped GET /api/v1/actors/me/authorization-context?project_id=....
Both resolve the canonical project and use current local grants only. Project
identity returns the registered full identity projection to effective Operator,
Project Manager, Finance Authority, or Audit Authority grants, and only id,
name, and status to exact-project Submitter or Reviewer grants.
The self context lists effective role names and active route-backed project
actions; it exposes no grant ids, identity-link data, planned actions, or
unrelated system authority.
AUTH-11C1 activates the five setup-run, sufficiency-report, and draft submission artifact policy GET actions. Each route resolves and locks the canonical project, guide/version, exact child or collection, and source-snapshot facts before requiring a covered Project Manager, scoped Audit Authority, or system Operator grant. Missing, cross-project, cross-guide, revoked, and stale bindings share the concealed project-read response. Issuer-provided role metadata is excluded from product decisions; contributor grants do not cover these diagnostics, and these read permissions provide no mutation authority.
| AUTH-11C1 public GET route | ActionId | PermissionId |
|---|---|---|
/api/v1/projects/{project_id}/guides/{guide_id}/setup-runs/latest |
project.setup_run.read |
project.setup_diagnostic.read |
/api/v1/projects/{project_id}/guides/{guide_id}/sufficiency-reports |
project.guide_sufficiency_report.list |
project.setup_diagnostic.read |
/api/v1/projects/{project_id}/guides/{guide_id}/sufficiency-reports/{report_id} |
project.guide_sufficiency_report.read |
project.setup_diagnostic.read |
/api/v1/projects/{project_id}/guides/{guide_id}/submission-artifact-policies |
project.submission_artifact_policy.list |
project.effective_policy.read |
/api/v1/projects/{project_id}/guides/{guide_id}/submission-artifact-policies/{policy_id} |
project.submission_artifact_policy.read |
project.effective_policy.read |
AUTH-11C2 hard-cuts three current active-guide reads to local administrative authority. Covered Project Manager and Audit Authority grants and system Operator grants may read them. Finance Authority, Access Administrator, project-role contributors, and services deny with the same concealed response as a missing or stale resource.
| AUTH-11C2 public GET route | ActionId | PermissionId |
|---|---|---|
/api/v1/projects/{project_id}/guides/{guide_id}/effective-submission-artifact-policy |
project.effective_submission_artifact_policy.read |
project.effective_policy.read |
/api/v1/projects/{project_id}/guides/{guide_id}/pre-submit-checker-policy |
project.pre_submit_checker_policy.read |
project.effective_policy.read |
/api/v1/projects/{project_id}/active-guide |
project.active_guide.read |
project.read |
The guide-bound policy routes expose only the approved/compiled chain for the current active guide and latest canonical snapshot. The strict active-guide response contains guide, source snapshot, sufficiency, submission artifact, effective, pre-submit checker, post-submit checker, review, and revision context. It excludes retired compensation configuration. Every returned row and source item is locked and hash-revalidated through projection and commit. Draft, superseded, replaced, incomplete, ambiguous, corrupt, or stale bindings conceal. Contributor guide requirements remain on task work-context and submission-requirements surfaces.
AUTH-12A registered the complete project-mutation vocabulary below as planned
and unavailable. AUTH-12C activates project.create, and AUTH-12D activates
the three draft guide/source-metadata actions identified below; every remaining
row stays planned. A planned action fails with action_unavailable before a
prepared handle or allowed decision evidence can exist. project.create alone
derives system scope; every other action derives the exact project from its
typed resource.
POST /api/v1/projects requires an active human, the exact active identity
link, an effective system-scoped Project Manager grant, and a UUID
Idempotency-Key. Project-owned replay state supplies stable server operation
and project identities before PREP. Final consumption binds those identities,
the validated body digest, actor, link, grant, generation, request transaction,
and action. The project shell, authorization event, provenance, and committed
replay result persist atomically. Verified-token role observations,
project-scoped grants, service
actors, copied handles, changed replay input, revoked authority, and stale or
wrong transactions do not authorize creation. This action creates no guide,
setup run, task, submission, checker, review, contribution, compensation,
reputation, policy, or activation state.
An exact committed retry is response recovery, not another creation attempt. It validates the same actor/action/key/request digest and the database-enforced committed custody chain, then returns the original response without new PREP or allowed evidence. Later grant revocation denies new or changed creation requests but does not rewrite an already committed idempotent response.
Guide creation and draft metadata updates require an active human with an
effective system-scoped or exact-project Project Manager grant carrying
project.guide.manage. Each public mutation requires a UUID Idempotency-Key
before actor first-access provisioning. Guide creation consumes distinct,
transaction-bound guide-create and internal source-consent PREP handles after
locking the project. It atomically commits the draft guide, complete document
set, paired same-key replay records and one awaiting_documents setup.
There is no separate public source-snapshot creation operation.
The create response supplies document IDs. The manager uploads each original
through POST /api/v1/projects/{project_id}/guides/{guide_id}/documents/{document_id}/content.
Exact membership and current ingest authority are checked before body reads.
Only committed bytes for every declared document can trigger automatic setup.
Broker dispatch happens after commit and never carries a prepared handle.
Guide-create replay reauthorizes both original actions against current authority
and returns the original document IDs and initial setup response.
Guide create/update no longer accept embedded review, revision, retired
payout/economic, or contribution-record configuration fields. Guide create
requires the complete document declarations and task examples stored as
immutable PostgreSQL metadata. AUTH receives the request digest, example hash and count; the guide
and exact replay response are committed together. Document/upload snapshots
bind that commitment and receive original PDF/DOCX/PPTX or UTF-8 Markdown
(.md) files through ART. Embedded Markdown bodies and URL/repository ingestion
are unavailable. Only bounded
metadata such as change_summary remains editable while the guide is draft.
For guide creation and document upload, exact committed retries return the
recorded response without another mutation, setup run, or dispatch. Changed, concurrent-pending, cross-project,
stale-lineage, revoked, wrong-action, wrong-resource, or wrong-transaction use
fails closed with no product write.
Review and revision policy configuration uses two separate guide-bound PUT
routes. Each requires an exact covered-project Project Manager grant, a UUID
Idempotency-Key, and an HTTP If-Match precondition: a quoted opaque selector
binding the current policy ID, generation, and digest for replacement or the
exact "no-current-policy" sentinel for initial
attachment. The server normalizes the complete policy semantics, computes the
canonical digest, consumes one transaction-bound PREP handle after locking the
draft guide and predecessor, appends an immutable version with authorization
provenance, and advances only that policy selector. Draft guides may attach the
two policies in either order; activation still requires both. Active guide
policy selection remains frozen.
Guide sufficiency has three active mutation actions. Public requests require a
covered Project Manager, canonical human actor/link resolution, and UUID
idempotency. PREP binds the draft guide/version, latest source snapshot/hash,
setup generation, report when applicable, operation/request digest, and final
material/stale-output facts. Agent execution occurs after cheap preflight and
outside any prepared handle; persistence obtains fresh authority. The fixed
workstream.project.setup service may resolve only the run action internally
with exact setup custody and no matched human grant.
Unified guide compilation separates request authority from provider execution.
project.guide_compilation.request requires a current exact-project Project
Manager grant; system-scoped grants do not substitute. Transaction-bound PREP
binds the actor, identity link, matched grant, immutable guide/setup lineage,
catalogue manifests, agent/instruction versions, and operation/request facts.
project.guide_compilation.execute belongs only to workstream.project.setup.
Its pre-provider check validates the complete typed attempt and provider key
without issuing a handle or writing authorization evidence. After provider I/O, fresh
PREP recomputes and verifies the complete result/component digest and commits
its allowed event only with POL-03B's immutable result transition. AUTH-12I
activates these authority boundaries only; it exposes no route, dispatches no
execution task, calls no provider, and does not make the hidden POL workflow live.
| ActionId | PermissionId | Activation owner |
|---|---|---|
project.create (active) |
project.create |
WS-AUTH-001-12C |
project.guide.create (active) |
project.guide.manage |
WS-AUTH-001-12D |
project.guide.update (active) |
project.guide.manage |
WS-AUTH-001-12D |
project.guide_source_snapshot.create (active internal paired consent) |
project.guide.manage |
WS-AUTH-001-12D |
project.review_policy.update (active) |
project.review_policy.manage |
WS-XINT-003-02B |
project.revision_policy.update (active) |
project.review_policy.manage |
WS-XINT-003-02B |
project.guide_sufficiency_report.create (active) |
project.guide.manage |
WS-AUTH-001-12E |
project.guide_sufficiency.run (active) |
project.guide.manage |
WS-AUTH-001-12E |
project.guide_compilation.request_automatic (active) |
project.guide_compilation.execute |
WS-AUTH-001-12I |
project.guide_compilation.request (active) |
project.guide_compilation.request |
WS-AUTH-001-12I |
project.guide_compilation.execute (active) |
project.guide_compilation.execute |
WS-AUTH-001-12I |
project.guide_sufficiency.warnings.acknowledge (active) |
project.guide.manage |
WS-AUTH-001-12E |
project.submission_artifact_policy.create (active) |
project.effective_policy.manage |
WS-AUTH-001-12F2 |
project.submission_artifact_policy.derive (active) |
project.effective_policy.manage |
WS-AUTH-001-12F3 |
project.submission_artifact_policy.update (active) |
project.effective_policy.manage |
WS-AUTH-001-12F2 |
project.guide_compilation.review_package.read (active) |
project.guide.manage |
WS-AUTH-001-12F4 |
project.guide_compilation.correction.request (active) |
project.guide_compilation.request |
WS-AUTH-001-12F4 |
project.submission_artifact_policy.approve (active) |
project.effective_policy.manage |
WS-AUTH-001-12F4 |
project.post_submit_checker_policy.approve (active) |
project.effective_policy.manage |
WS-AUTH-001-12G |
project.post_submit_checker_policy.correction.request (active) |
project.effective_policy.manage |
WS-AUTH-001-12G |
project.post_submit_checker_policy.derive (active) |
project.effective_policy.manage |
WS-AUTH-001-12G |
project.setup_run.update (active) |
project.guide.manage |
WS-AUTH-001-12B2 |
project.guide.activate (public through AUTH-18) |
project.guide.manage |
WS-AUTH-001-12H, WS-AUTH-001-18 |
The v0.1 baseline preserves historical sufficiency rows as readable, unattributed records while requiring complete creation or acknowledgement authority provenance for new 12E mutations. Its replay ledger is append-only. Operators must preserve authority and product evidence and recover forward.
WS-AUTH-001-12F is a planning-only parent and activates nothing. 12F1 owns
the zero-activation PREP/replay/provenance foundation; 12F2 owns explicitly
manual Project Manager drafts; 12F3 owns automatic fixed
workstream.project.setup derivation and removes public inline derivation; and
12F4 owns Project Manager authority over the POL-05A atomic effective/pre-submit chain.
POL-04A2 provides the hidden finalization service and dependency-free AUTH
contracts; its default authorization port remains unavailable. The
project_guide_setup_finalization audit resource binds the immutable receipt
to exact final facts, actor, identity link, project scope, and stored decision.
AUTH-12B2 supplies the explicit concrete adapter over this boundary. Only fixed
workstream.project.setup may consume project.setup_run.update against the
exact finalization resource; human, direct-kernel and legacy setup resources
deny. Preparation binds actual actor/link, project, operation and correlation
custody. Fresh replay rechecks current lifecycle authority and the exact stored
allow envelope and digest, including a null denial code, without another allow
event. POL retains transaction and immutable receipt ownership. The default
port remains unavailable; POL-04B explicitly composes the authorized adapter
in the live Celery setup path. POL-05A delivers hidden complete proposal review,
correction and pre-submit approval. AUTH-12F4 supplies exact manager authority; POL-05B exposes the exact public proposal operations and manual correction dispatch. Complete proposal content uses current exact-project manager
project.guide.manage authority; diagnostic-read authority alone is insufficient. AUTH-12G gates deterministic
post-submit policy derivation with the fixed setup identity and separate approval
or correction with a current exact-project manager grant; neither approval gate is required for draft finalization.
The post-policy adapter consumes the POL-owned finalization, upstream approval,
projection, source, catalogue, effective/pre-submit and policy commitments without
recomputing business identity or policy content. Its complete draft read reuses
project.guide_compilation.review_package.read with project.guide.manage;
private preparation distinguishes post-policy and unified-proposal operations,
so their handles cannot be exchanged. Mutation evidence retains the exact public
facts digest. Replay locks fresh current authority and checks the original exact
decision without another allow or product write. Correction consumes both the
post-policy and unified-proposal authorities in the caller's one root transaction,
then records one shared successor. POL-06B exposes these public manager operations
and delivers deterministic derivation through the fixed setup service after
upstream approval commits. Recovery reloads the exact approval custody and
prepares fresh service authority in a separate root transaction.
The 12F1 foundation binds each future submission-policy handle to the exact
project/guide/source lineage, mutation target, operation and request digests,
policy generation, actor/link and grant-or-fixed-service custody, and current
root transaction. Unified approval replaces the manual approval resource. Its canonical proposal
commitments bind both catalogues, complete result/component hashes and the
actual compiled/effective output hashes through the POL-owned target and receipt. Its replay reservation distinguishes human
idempotency from fixed setup-service task custody. Manual mutations permit only
pending -> committed. Fixed-service derivation uses the 12F3 one-way
reserved -> pending -> committed state machine: reserved is committed before
material or agent I/O, while the final two transitions commit atomically with
the derived policy, final AUTH evidence, and setup output.
The v0.1 baseline preserves existing product rows in
the all-null unattributed shape until their owning route cutovers. 12F2 now
activates only manual human create/update. Manual update appends a separately
authorized successor, binds predecessor hash and successor identity through
PREP/replay, and supersedes the predecessor in the same root transaction.
Diagnostic sufficiency, token role strings, services, contributors, and
agent-derived rows cannot authorize this exception. Fixed-service derive is
active under 12F3; human unified-proposal authority is active under 12F4, with
public exposure supplied by POL-05B. Any durable
execution claim or replay row—including reserved or pending—or attributed
provenance must be preserved. Submission-policy authorization audit events,
including denied evidence, must also be preserved.
The v0.1 baseline extends only the closed audit action-to-permission evidence constraint. It includes the verified guide-materialization schema, adds no permission, and requires direct or idempotency-linked evidence to be preserved.
The two collection routes return and transactionally bind at most the newest 100 canonical rows in deterministic newest-first order. Older retained records remain available only through their exact individually authorized read route.
WS-AUTH-001-CONTRIBUTOR-FOUNDATION established TaskAssignment and Submission
contributor_id references to canonical human ActorProfiles in PostgreSQL.
The task-project-grant authorization change replaces its exclusive write-guard
wrapper and self-activated eligibility bridge with existing canonical AUTH.
TASK locks the task and active assignment before AUTH locks the exact current
profile, identity link and applicable grant. Claim/start/contributor context
require an active exact-project Submitter grant; manager context and reasoned
Operator start use their separate canonical permissions. Token role strings
do not authorize these operations. Command denials use
permission_not_granted; database unavailability rolls back with retryable
task_authority_unavailable. Identity resolution retains its own earlier
failure contract.
The public JSON packet-creation POST is removed, not aliased or replaced by a second authorization path. Existing admission-backed creation stays hidden, uses TASK-first locked context and canonical submission authority, and preserves atomic ART consumption. Retained contributor data and submission reads remain.
The implementation order is fixed by the WS-AUTH-001 chunk map:
WS-AUTH-001-01: canonical docs and ADR;WS-AUTH-001-02: verified issuer token/JWKS boundary;WS-AUTH-001-03: legacy actor classification;WS-AUTH-001-04: request/error/rate controls;WS-AUTH-001-05: authority evidence/idempotency;WS-AUTH-001-06: canonical actor/link migration;WS-AUTH-001-07: authorization kernel;WS-AUTH-001-08: bootstrap/admin grants;WS-AUTH-001-09A: fixed service identity and static matrix foundation;WS-AUTH-001-09B: controlled service ActorProfile/ActorIdentityLink provisioning with an unverified service link until AUTH-09E verifies the service token;WS-AUTH-001-09C: actor and identity-link administrative reads;WS-AUTH-001-09D-A: lifecycle evidence repair and actor-profile suspend, reactivate, and terminal deactivate;WS-AUTH-001-09D-B: identity-link revoke/reactivate and mixed lifecycle race closure;WS-AUTH-001-CONTRIBUTOR-FOUNDATION: canonical-human TaskAssignment and Submission attribution plus transaction-local active identity revalidation;WS-AUTH-001-09E: fixed service runtime admission without human grant evaluation or feature action activation;WS-AUTH-001-ART-CUSTODYandWS-AUTH-001-REV-CUSTODY: availability-neutral transfer to exact AUTH activation owners;WS-AUTH-001-PREP: prepared mutation authorization protocol;WS-AUTH-001-10: independent project contributor grants, with 10B1 establishing durable authorization-read rate control before 10B2 exposes candidate and grant-history reads;WS-AUTH-001-11throughWS-AUTH-001-14: complete resource-family cutovers;WS-AUTH-001-15: obsolete authority removal and scanner enforcement;WS-AUTH-001-16: conformance, observability, concurrency, and live API proof.
No implementation may add a compatibility alias, fallback authority source, dual route, or translation into canonical grants. The remaining explicitly enumerated legacy paths are removal-only: their allowlist may only shrink, and their assigned cutover must delete them rather than preserve an alternate path. No implementation chunk may create a second canonical actor root, verifier hierarchy, audit ledger, unit-of-work abstraction, or authorization engine.
Errors use a stable envelope and denial codes. They do not contain raw exceptions, tokens, full claims, secrets, JWKS material, private artifact content, or unnecessary personal data. Unauthorized resources are concealed where existence itself is sensitive.
First access and administrative mutations are rate-controlled through
Postgres-backed fail-closed controls before their public APIs become available.
The v0.1 baseline extends that same durable
counter with the closed authorization_read scope. Its dependency remains
unattached and activates no action until AUTH-10B2. The dedicated default is
120 requests per 60 seconds per verified issuer/subject digest, independently
configurable within the existing bounded limit and window ranges.
AUTH-10B2 activates only project.contributor_candidate.list,
project_role_grant.list, and project_role_grant.read. Their canonical targets
are the server-loaded project and, for detail, the grant joined through that
project. Candidate discovery is Project-Manager-only and permits draft, active,
and paused projects; grant history permits covered Project Manager or Audit
Authority access in every project state. Services and unsupported agent/Space
subjects are concealed before project lookup. Authorization denials, missing
resources, project/grant mismatch, and candidate lifecycle denial use one public
404 shape while bounded kernel denials retain their established audit evidence.
Candidate pages expose exactly actor profile ID plus nullable display name.
Grant pages accept only optional active/revoked status and
submitter/reviewer role filters, a 1..100 limit (default 50), and a
cursor bounded to 512 characters. Each grant exposes exactly id, project_id,
actor_profile_id, role, status, version, grant_method,
qualification_snapshot, both granting actor/admin-grant identifiers,
granted_at, grant_reason, and the three present-but-nullable revocation
fields. The nested snapshot exposes exactly its ID, requested role, bounded
skills and reputation availability/reference objects, prior-project and
external-expertise references, both capturing actor/admin-grant identifiers,
and capture time. Both page
envelopes are exactly items and next_cursor, without totals. A strict signed
keyset cursor binds action, project, normalized filters, limit, ordering,
timestamp, and UUID. The required independent 32-byte Base64 cursor HMAC key
fails startup when absent or invalid; coordinated rotation invalidates all
outstanding cursors. AUTH-10B2 adds no migration and does not change PREP or
grant mutation behavior.
Each owning chunk must prove:
- allow and deny cases for every permission path;
- migrated surfaces derive product authority only from local grants and guards;
- cross-project and concealed-resource behavior;
- immediate same-token revocation;
- state/grant/link and final-administrator concurrency;
- idempotent exact replay and mismatched replay rejection;
- append-only allowed and denied evidence;
- preserved current intake lifecycle through the full backend suite and API contract drill;
- no test skip, xfail, assertion weakening, dependency override, fabricated authorization context, or direct grant insertion as product proof.
- every protected route and asynchronous command migrated by that chunk has one primary registered action declaration, a canonical target derived through its owning feature boundary, and allow/deny tests for its mandatory guards.
Final chunk 16 proof includes a generated /api/v1 route and asynchronous
command manifest. It fails closed on an unknown permission or resource type, a
duplicate or missing primary declaration, or an unregistered guard. The manifest
is conformance evidence, not a second policy source.
Each activating chunk must prove exact authority, denial, revalidation and transaction behavior with focused regressions and full hosted execution. Coverage percentages are diagnostic, not an activation or merge gate.
The final live drill must operate through supported APIs/commands without direct database authority edits.
This specification and ADR 0012 supersede active token-role and typed-profile authorization claims. ADR 0006 still controls authentication ownership. WS-REV-001 and WS-CON-001 control their own product behavior.
This specification does not add Workstream login, implement runtime code, change review decision values, define contribution/compensation behavior, add a frontend, enable blockchain settlement, add source adapters, automate routing, or create an agent workspace.
project.guide_compilation.request_automatic requires current fixed
workstream.project.setup authority and the existing compilation execution
permission. The request records automatic_source_ready plus the exact committed
source mutation operation and source authorization event. Human requests record
project_manager with neither source selector. Mixed or incomplete tuples deny.
Source consent is immutable; later revocation of its original manager does not
turn the service into that manager. Request replay still requires the requesting
actor's current authority, held through receipt classification. Automatic input
is resolved from owned source/setup rows and verified ART material; callers
cannot supply provider input or claimed context hashes. Neither trigger approves
or activates guide policies.
project.guide.activate is publicly exposed by AUTH-18 through AUTH-12H's explicit adapter
for CP07's sole activation operation. Only a live human Project Manager with an
exact-project grant may prepare it. System-scoped manager grants and service
identities are insufficient. The operation acquires shared authority locks before
product resources and consumes one request/session/root-transaction-bound PREP
handle over CP07's complete immutable facts. AUTH uses the owner's exact digest,
not a separately reconstructed policy chain. The allow event contains bounded
selectors and that digest, never the policy body or guide material.
Replay validates the original event under fresh live authority and returns the
original receipt without another activation or decision. Readiness and policy
selection remain CP07 responsibilities; unavailable automated acceptance still
blocks human_review_required=false. The existing exact-manager post-policy read
also discloses activation selections, with the complete response bound to its
authorization digest; this grants no Finance policy-body access.
outbox.dispatch is active, with sole fixed identity
workstream.outbox.dispatcher. No human role receives it. The existing administrative
service provisioning operation supplies the actor and identity link; missing,
suspended/deactivated or revoked provisioning denies delivery. Claim/invoke/finalize facts bind outbox_event, exact event
and project, payload digest, generation, claim owner and UTC lease. Finalize
also requires the exact OUTBOX-owned outcome digest. These facts and decisions
are not portable authority. The live adapter uses canonical PREP, holding service
profile/link locks before event/attempt locks. CON-02B owns committed claim/lease
validation and outcome hashing. AUTH-OUTBOX-02 binds exact recomposed facts and
stores immutable claim/invoke/finalize audit references with matching SQL guards.
Historical replay retains its original references and consumes fresh live authority. A pre-invocation decision cannot authorize post-I/O finalization.
The closed actions task.read and task.submission_requirements.read use
task.queue.read with an active exact-project Submitter grant. Their guard is
ready/unassigned work or the exact own active assignment, matching work context.
project.task.read and project.task.submission_requirements.read use
project.task.manage with a covering project- or system-scoped Project Manager
grant. They are read actions, separate from manager command receipt/state guards.
No new permission or token-role fallback is introduced.
TASK owns the transaction and locks task/assignment before AUTH actor/link and grant; historical policy locks follow for requirements. Exact PREP facts and matched-grant evidence precede projection; DTO validation/serialization precedes commit. Missing and unauthorized reads conceal consistently, without changing claim/start command errors. Database migration 0003 admits only these four exact action/permission pairs after the UUIDv7 baseline and queue migration.
project.task.locked_context.read uses project.task.manage with a covering
Project Manager grant. operations.task.locked_context.read uses
operations.status.read with a system Operator grant. audit.task.locked_context.read
uses audit.read with a covering Audit Authority grant. Exact role filters apply:
other administrative roles sharing audit.read cannot use the audit projection.
No grantable permission is added. Token roles and task creator identity do not
authorize these operations.
The shared concealed-read guard rejects mutation/replay fields. TASK filters project and task before locking, then acquires assignment, actor/link and grant locks before resolving historical PROJECTS custody. All task states are readable only with complete valid locked context. Nonhuman admission and missing/foreign/ denied reads conceal with 404; malformed selectors and invalid custody return 422. Serialization occurs before ALLOW commit. Migration 0004 extends the existing audit constraint with only these three exact action/permission pairs and preserves retained evidence. The prior task-only route is removed.
audit.task.evidence.read uses audit.read but explicitly filters to covered
Audit Authority grants; all other admin roles sharing that permission are denied.
It reuses TASK PREP and the concealed-read guard, rejects command/replay fields,
and binds exact task facts. TASK owns scoped task/assignment locks before AUTH
actor/link and matched grant, then reads the fixed bounded evidence projection.
Every page revalidates current authority; cursor position confers none. All states,
including draft without policy locks, are inspectable. Page serialization precedes
ALLOW commit. Database migration 0005 adds only this exact action/permission pair
and retains previous evidence. This is not an authorization-decision export.
The TASK history contract defines eight exact read actions and distinct contributor/manager projections. AUTH stages a fresh matched-grant decision; the caller commits it only with a validated response. Authentication has no token-role compatibility projection or identity-observation writer. Retained actor classification data remains evidence, never an authority source. No manual checker or finalize-repair route survives.
The dependency-free AUTH source/receipt value contracts do not verify stored records or grant permissions. The human contract binds the allocated Review and ReviewDecisionRequest, the caller key and request/aggregate digests, exact packet and policy lineage, and the delivered reviewer ContributionPolicyVersion ID. Initial decisions have no inherited blockers. Accept requires zero new or inherited open blockers; needs_revision requires at least one, with at most 100 combined.
The TASK-owned routing digest commits every revalidated manifest fact except
PostgreSQL-owned created_at. Private AUTH projects those public facts into the
routing source commitment, adding a distinct route_operation_id and
route_request_digest. These never reuse checker evaluation authority. Both locked
ReviewPolicy branches remain representable; construction does not enable either.
ARCH-04E2-A binds the exact reserved request, source and outbox claim to one
closed branch consequence. True contains only the TASK
evaluation_pending -> review_pending transition and no REV queue fields. False
contains the exact TaskAcceptedEffectsRequest, including its allocated
FinalAcceptance identity, for later shared acceptance without a fabricated Review.
Human receipt request/correlation identify its operation; idempotency_reference identifies its ReviewDecisionRequest, separately from the committed caller key. Routing receipt request/correlation/idempotency all identify the routing operation. The receipt binds exact action/permission, actor and identity link, project, resource, source commitment and full resource digest. Human facts require the reviewer and a matched grant, with no service identity; routing facts require the fixed router identity and no grant. The resource types are review and task_post_submit_routing_manifest respectively. Detached values are untrusted: future consumers must compare the actual immutable event and stored source.
Domains workstream.task_post_submit_source.v0.1 and workstream.authorization.acceptance_source.v0.1 separate retained source facts from the opaque full runtime resource digest. Current audit events do not yet persist this new source commitment. ARCH-04E1B-A stages routing request facts; 04E2-A provides strict hidden AUTH resource/preparation matching and the nominal fixed-router adapter through canonical PREP. The action remains planned and the kernel rejects before handle issuance, so the adapter cannot return an allow or receipt and performs no source, publication or product write. CON-07 hidden submitter participation and REV-04C hidden FinalAcceptance/TASK/CON composition are delivered; hidden handlers are next for the selected automated path. Mandatory exact same-input receipt and persisted source/FinalAcceptance custody follow at 04E2-B, with the first genuine allow and all governed effects in the same transaction, before production composition or consumption. No early standalone allow exists. The actor-vocabulary migration provisions nothing, and existing closed audit constraints still reject a route allow.