Codex 0 · Chapter 09 — Cross-Division Workflows

This chapter specifies the stage model that every cross-division workflow must be written in, and fully specifies WF-01 through WF-07 in that form.

9.0 Purpose

A workflow is the unit by which Anabasis makes a cross-division promise implementable and auditable. Codex 0 §6 names seven workflows in prose; this chapter is their binding specification. No workflow may be built, or claimed as built, until its stages are written in the form defined here.

9.1 Scope and non-scope

This chapter specifies:

1. 1The workflow model — what a stage is, and what every stage must declare.
2. 2The full stage-by-stage specification of WF-01 through WF-07.
3. 3Rules for long-running state, abandonment, and reversal of an issued credential.

This chapter does not specify: the engines that stages call into (Chapter in Codex 3), the API boundaries stages cross (Chapter 10), the entities stages emit (Codex 5), or the surfaces a person uses to act on a stage (Chapter 11). A workflow stage names these by ID; it does not redefine them.

9.2 The workflow model

9.2.1 Definition

9.2.1.1 A workflow is a named, ordered sequence of stages that moves a Person, Organization, or Venture from one institutional standing to another, crossing at least one division boundary or one authority boundary (Academy grading, Stewardship review) along the way.

9.2.1.2 A workflow is not a UI flow. A UI flow may present several stages as one screen, or one stage across several screens; the stage boundary is defined by what changes in the data model and who is accountable for it, not by screen count.

9.2.1.3 Every workflow has exactly one owning division (Codex 0 §16, field 6), recorded in the registry (WF- entries, CODEX-0-REGISTRY.md §4). Ownership of a workflow does not grant ownership of the entities or engines it touches; those retain their own owners.

9.2.2 The stage record

Every stage of every workflow is written using exactly these seven fields. A stage with an unanswered field is not implementable and may not be marked built in the registry.

Stage <n> — <name>
Actor        who or what initiates or performs the stage (a role, Codex 4 name,
             or an agent, AGT- ID)
Precondition what must already be true of the data model for the stage to begin
Action       what the stage does, in one sentence, naming the engine(s) or
             API boundary(ies) invoked (ENG- / API- ID)
Emits        the canonical entities created or mutated (ENT- names, Codex 5)
Audit point  whether this stage produces an AuditRecord (ENT-19), and under
             what reason string
Failure      what happens if the action cannot complete, and what state the
             person is left in
Reversal     how this stage's effect is undone, or "irreversible" with the
             stated reason

9.2.3 Clauses binding all workflows

9.2.3.1 Every stage that changes a person's standing produces an AuditRecord (Codex 0 §6, restated). "Standing" means: any change to Membership, Role, CapabilityAssessment, Credential, Enrolment status, or Investment.

9.2.3.2 A stage's Action names the engine or API boundary it invokes. A stage that cannot name one either does not belong in the workflow or exposes a missing boundary — in which case the gap is recorded, not silently bridged with ad hoc code.

9.2.3.3 A stage may not skip its Precondition by inferring it from a later stage's success. Preconditions are checked, not assumed.

9.2.3.4 A stage's Failure path must leave the entity graph in a valid, nameable state — never a partially-written record with no status. Every long-running entity (Enrolment, Engagement, Venture) carries a status field whose values are enumerated in this chapter's per-workflow tables.

9.2.3.5 Reversal is a first-class design question, not an afterthought. A stage marked "irreversible" must state why (typically: a downstream party has already relied on the output — a public verification, a signed investment, a filed report).

9.2.3.6 No stage may be implemented against an API boundary that has not reached at least experimental stability (Chapter 10 §10.2). Internal workflows do not get a private path around boundary stabilisation.

9.2.4 Long-running state

9.2.4.1 A workflow instance (one Person's enrolment, one Venture's pipeline run) is long-running when its stages span more than one session and may span months or years (WF-01, WF-04, WF-05 are long-running by design; WF-06, WF-07 are not).

9.2.4.2 Every long-running workflow instance carries an explicit status entity distinct from the entities its stages emit — e.g. Enrolment.status, Venture.stage — so that "where is this instance right now" is answerable by one query, not by replaying stage history.

9.2.4.3 A long-running instance's status is one of: active, paused, abandoned, completed, reversed. No fifth ad hoc status may be introduced without a decision record.

9.2.5 Abandonment

9.2.5.1 Abandonment is a status, not a deletion. A Person who stops mid-enrolment, mid-engagement, or mid-venture-pipeline retains their record; no workflow silently deletes progress for inactivity.

9.2.5.2 A workflow instance moves to abandoned only by one of: an explicit person action (withdraw, cancel), or an institutionally-defined inactivity threshold stated in the workflow's own specification (below), never by a default system timeout invented outside doctrine.

9.2.5.3 Abandonment never forfeits demonstrated capability already recorded. A CapabilityAssessment or Credential already issued before abandonment stands; only the unfinished portion of the workflow is marked abandoned.

9.2.5.4 Abandoned instances may be resumed. Resumption re-enters at the last stage whose Precondition still holds; earlier stage outputs are not re-run.

9.2.6 Reversal of an issued credential

9.2.6.1 A Credential (ENT-08) is the highest-consequence output any workflow produces. Reversal of an issued credential is possible but is never a delete.

9.2.6.2 Reversal is recorded as a new, dated Credential status transition (active → revoked), never as removal of the original row. The original issuance record and its evidentiary chain (CapabilityAssessment, Artifact) are retained permanently.

9.2.6.3 A revoked credential is stated as revoked, with a reason, at the same public verification endpoint (API-05) that would have confirmed it as active. Verification of a revoked credential is not indistinguishable from verification of one that never existed.

9.2.6.4 Only an authority separated from the issuing faculty may initiate revocation (Codex 0 §8: authority to define a standard is separated from authority to issue against it; revocation follows the same separation). The reviewing body is named per credential class in Academy governance, not invented per case.

9.2.6.5 Revocation produces an AuditRecord naming the reviewing authority, the reason, and the evidence reviewed. It is never silent.

9.2.6.6 Revocation does not retroactively unwind downstream consequences already taken in good faith by a third party before the revocation date (e.g., a hiring decision) — it changes the record going forward and is timestamped, so all downstream consumers can determine what was known when.

9.3 WF-01 — Enrolment to credential

Owner: DIV-01 (Academy). Actors: Scholar, Faculty, Reviewer, AGT-04. Depends on: API-03, API-04, API-05. Status: partial (Codex 0 Registry).

9.3.1 Stages

9.3.2 Lifecycle diagram

 Public visitor
      |
      v
 [1 Intake] --(withdraw)--> abandoned
      |
      v
 [2 Baseline] --(skip)--> default path
      |
      v
 [3 Recommended path] <--(override)-- Scholar
      |
      v
 [4 Enrolment: active] ------(withdraw)-----> [abandoned] --(resume)--> [4]
      |
      v
 [5 Lesson completion] <--(revisit)--
      |
      v
 [6 Assessment submission] --(fails validation)--> [returned to Scholar] --> [6]
      |
      v
 [7 Review: AGT-04 -> Faculty if weighted] --(inconclusive)--> [Faculty] --> [7]
      |
      v
 [8 CapabilityAssessment recorded] --(below threshold)--> [4: active, no credential]
      |
      v
 [9 Credential issued: active] ------(revocation, 9.2.6)------> [Credential: revoked]
      |
      v
 [10 Public verification record] <--------- always reflects current status --------|

9.3.3 WF-01-specific abandonment rule

An Enrolment with no Event for a period stated in Academy operating policy (not this Codex) may be flagged for outreach; it moves to abandoned only on Scholar action or a stated policy threshold recorded in a decision record, never a silent default.

9.4 WF-02 — Credential to advisory engagement

Owner: DIV-02 (Advisory). Actors: Advisor, Enterprise client. Depends on: API-05, API-06. Status: reserved.

9.5 WF-03 — Research to curriculum

Owner: DIV-03 (Research Institute). Actors: Researcher, Editor, Faculty, AGT-03. Depends on: API-07, API-09, API-03. Status: reserved.

9.6 WF-04 — Founder intake to venture to capital

Owner: DIV-04 (Ventures). Actors: Founder, Investor. Depends on: API-08. Status: reserved.

9.7 WF-05 — Enterprise client to cohort

Owner: DIV-01/DIV-02 (joint). Actors: Enterprise client, Faculty. Depends on: API-03, API-06, API-10. Status: reserved.

9.8 WF-06 — Alumni to mentor

Owner: DIV-01. Actors: Mentor, Scholar. Depends on: API-02, API-05. Status: reserved.

9.9 WF-07 — Annual accounting

Owner: DIV-06 (Executive Office). Actors: Executive, Steward. Depends on: API-10. Status: partial.

9.10 Interfaces

9.10.1 Every workflow stage's Action names exactly one engine or API boundary as its point of integration. Stages calling more than one must be split.

9.10.2 Workflow status entities (Enrolment.status, Venture.stage, Engagement.status) are read by dashboards (Chapter 12) through the same API boundaries as any other consumer — no workflow exposes a private status field to a single dashboard.

9.10.3 A workflow that spans two divisions has its owning division named in the registry; the counterpart division's stages are still specified in full here, and the counterpart division may not silently fork its own version.

9.11 Invariants

1. 1Every stage declares actor, precondition, action, emits, audit point, failure path, and reversal path, or it is not specified.
2. 2Every stage that changes a person's standing produces an AuditRecord.
3. 3Abandonment is a status, never a deletion, and never forfeits already-recorded capability.
4. 4A Credential is never deleted; it is only ever issued, then optionally revoked, both dated and both visible at the verification endpoint.
5. 5No workflow instance may exist with an unrecognised status value.
6. 6A workflow may not be marked built in the registry unless every one of its stages is implemented against a boundary of at least stable class (Chapter 10).

9.12 Prohibitions

1. 1No workflow stage may write directly to another division's owned entity without going through that division's declared engine or API boundary.
2. 2No workflow may silently auto-advance a person's standing (auto-pass an assessment, auto-issue a credential) without the review stage specified for that workflow.
3. 3No workflow may delete a record of demonstrated capability to simplify a data model.
4. 4No workflow may introduce a status value not enumerated in 9.2.4.3 without a decision record.
5. 5No workflow implementation may bypass the failure or reversal path specified here for the sake of a simpler happy path.

9.13 Open questions

1. 1The specific inactivity thresholds that trigger abandoned status for WF-01, WF-04, and WF-05 are owned by each division's operating policy and are not fixed in this Codex; they must be recorded as decision records when set.
2. 2The credential classes for which revocation authority is separated from issuing faculty (9.2.6.4) are not yet enumerated; Academy governance must produce this list before TOOL-03 is built.
3. 3WF-05's "agreed scope" for aggregate reporting needs a standard contract clause set, not yet drafted, to prevent scope drift becoming a per-client negotiation each time.
4. 4Whether WF-02's anonymized case contribution (stage 6) needs a standing consent template versus per-engagement consent is undecided.

9.14 Governing Codices

Codex 1 (Article VI, non-negotiables on auditability and credential integrity); Codex 0 §6 (workflow narrative); Codex 0 §16 and CODEX-0-REGISTRY.md §4 (registry entries, IDs, and the eight-question record); Codex 2 (division definitions); Codex 3 (engines invoked by stage actions); Codex 4 (roles named as actors); Codex 5 (entities emitted); Codex 9 (decision records referenced in 9.9 and 9.13).