Enumerations Reference

Status: v1.41 (living document — updated as enums evolve) Owner: datapipelines.co core Purpose: Single source of truth for every enum value used across the system. Prevents spelling drift across specs and across the codebase.

How to use this document

• Every enum used in datapipelines.co is cataloged here.
• Specs may inline enum values for readability, but this document is the authoritative reference.
• If a value appears in code or a spec that doesn't match this document, the spec/code is wrong.
• When adding a new enum value: add it here first, then propagate to specs and code.
• Values are additive-only per the stability promises in individual specs.
• Each enum has exactly ONE authoring spec (see the cross-reference table). Other specs are consumers.
• Values marked (reserved) are registered for future use — they MUST NOT appear in generated code or be accepted by validators in v1.

Case & serialization convention

The strings cataloged here are the wire values — what appears in JSON payloads, exactly as written (case included). Kotlin enum classes use UPPER_SNAKE_CASE constants with an explicit mapping to the wire value:

enum class WriteMode(@JsonValue val wire: String) {
    REPLACE("replace"),
    APPEND("append");

    companion object {
        @JsonCreator @JvmStatic
        fun fromWire(v: String) = entries.firstOrNull { it.wire == v }
            ?: throw IllegalArgumentException("Unknown WriteMode: $v")
    }
}

Where the cataloged value is already UPPER (DQL, POSTGRES, SUCCESS), wire and constant coincide. Never rely on default Enum.name serialization for lowercase/kebab/snake wire values — the explicit @JsonValue mapping is mandatory so the catalog string stays the single source of truth.

1. LogicalType — canonical data types

Source: Type System §3 Used by: every spec — this is the foundational type vocabulary.

Excluded from parameters declarations: NULL (only the other 10 may be parameter types).

2. NodeType — pipeline node SQL category

Source: Pipeline Contract §4.6 Used by: pipeline-contract, dag-executor.

Reserved for future: EXPRESSION, HTTP (non-SQL node types — see ROADMAP).

3. OutputTarget — where a DQL node's ResultSet goes

Source: Pipeline Contract §4.7 Used by: pipeline-contract, dag-executor, staging.

Reserved for future: kafka, s3, email, webhook (see ROADMAP).

4. WriteMode — for output.target: "datasource"

Source: Pipeline Contract §4.7 Used by: pipeline-contract, dag-executor.

5. Dialect — supported source database dialects

Source: Type System §5 (single authority) Used by: datasources (driver dispatch), templates (template targets a dialect), pipeline-contract (validation: template dialect must match datasource dialect).

Reserved for future: SNOWFLAKE, BIGQUERY, REDSHIFT (see ROADMAP).

5A. CredentialKind — what a datasource's stored credential IS

Source: Datasources §3.4 (single authority) Used by: datasources (validation, pool build, encryption), rest-api (POST /api/v1/datasources), mcp-server (datasources_get reports the kind; there is no MCP create — MCP Server §6.2.22), metadata-db (datasources.credential_kind).

Wire values are lowercase snake_case, so the @JsonValue mapping is explicit per the case convention above.

These are not (reserved) values in the enums.md sense: all five are accepted by the validator and stored by the column. What a shipped dialect can USE is narrower and is the adapter's declaration (supportedCredentialKinds, Datasources §3.4) — a kind outside a dialect's set is refused at save with datasource.validation.properties_invalid, never stored and ignored.

6. TemplateEngine — template language

Source: Templates §4 Used by: templates (engine dispatch).

Reserved for future: pebble, handlebars, thymeleaf-sql (see ROADMAP).

6A. TemplateType — template kind

Source: Template Hierarchy §5; the script types: transform-nodes design §2.1 (7b) Used by: templates (engine-configuration dispatch, type/dialect consistency), pipeline-contract (reference legality).

Fixed at template create and identical on every version of a template (template.validation.type_immutable). Serialization is the lowercase wire value ("sql" / "html" / "jsonata" / "javascript"), per the case convention above. There are no reserved future values — component sub-typing (kpi, aggrid, svg, form, …) belongs to the future dashboard abstraction and is deliberately absent here (design §2).

7. StagingEngine — tempdb engine

Source: Pipeline Contract §5 Used by: pipeline-contract (settings.tempdb.engine), staging (factory dispatch), dag-executor (instantiation).

Reserved for future: DUCKDB (in-memory DuckDB — better for analytical workloads; see ROADMAP).

Declaration reality (2026-08-08). The frozen module dependency graph (module-structure §4.2) makes the "pipeline-contract authors, staging consumes" line above impossible: staging depends only on typesystem, so it cannot see a type declared in pipeline-contract. In v1 the enum has a single value (H2), so pipeline-contract declares it (for the settings.tempdb.engine wire value, with @JsonValue) and staging declares an identical local enum class StagingEngine { H2 } for StagingFactory dispatch; dag (which depends on both) maps between them — trivial while there is one value. Consolidation is a P4/dag decision: when a second engine (DUCKDB) lands, move StagingEngine into typesystem (the shared lower layer, exactly as Dialect resolved the same class of problem) so there is one authority. Until then the duplication is bounded to a single constant and dag owns the mapping.

8. UserKind — what a users row is

Source: Auth §4.7; metadata-db §4.1 (users.kind, V34, CHECK chk_users_kind) Used by: auth (UserKind, User.isHuman, UserService, UserRepository), the session filter, every user-administration route, ActorNames (history's "<key name> (API key)").

One predicate — kind = 'human' — guards every login, linking and administration path (auth §4.7). V34 backfilled system on the System row and human on every other; the wire and database token is the lowercase name.

(Until #215 slice (b) this section was Scope, the API-key credential axis; scopes were removed — see §8D.)

8B. Permission — an action a role may perform (was Capability)

Source: Auth §7.6 — the catalog table is the single authority (the value set, the roles each value admits, the surfaces placed on it); the permissions and keys record §2 (#215, ratified 2026-09-23) is its design. Used by: auth (Permission, RolePermissions, ScopeMatrix.allowed, AuthenticatedPrincipal.holds), every REST handler (@RequiredScope(Permission.X)), every MCP tool (its catalog entry, McpToolCatalog.Entry.permission), and the service checks that ask for one (execution.read_all, server_key.create, …).

Since #215 slice (a) a permission is a <functionality>.<permission> catalog value — pipeline.read, template.release, workspace.members.manage — one per piece of functionality a person can take separately (PK1); 65 on this version. The wire form is the dotted token; the Kotlin constant is its upper-snake spelling (PIPELINE_READ). The seven coarse values of v1.16 (view, execute, author, promotion_read, promote, ws_admin, super_admin) are retired: every one maps onto the catalog values whose surfaces it covered, with each surface's roles unchanged. The values are not restated here — a second list is a second thing to keep true; read them in auth §7.6.

It is the ROLE axis. It travels with a membership, not with a credential: the same person is a viewer in one workspace and an author in another. Not a hierarchy: the roles are not a chain, so the ONE role table (RolePermissions) lists each role's permissions outright. A super admin (users.is_admin) holds every value in every workspace (D7) except the two fenced promotion-receiving values, which no member role holds — only the promotion_receiver key role (§8D) does. Code asks whether a principal holds a permission; it never compares role names (PK1).

One axis since slice (b): scopes were removed (#215, PK8), so a permission is held by ROLES only — the four member roles and super admin (the §7.6 member columns), and the two key roles (§8D).

8C. WorkspaceRole — the ONE role a membership holds

Source: Auth §11A; metadata-db §4.12 (workspace_members.role, V29) and §4.17 (workspace_invitations.role) Used by: auth (WorkspaceRole, the role table RolePermissions), the REST role field of the workspace surface (rest-api §17), the members dropdown (ui-screens §4.13).

Exactly one per membership (roles design D1, 2026-09-20). Super admin is NOT a value: it is users.is_admin, a property of the user, held in every workspace. The wire and database token is the lowercase name; the UI prints it with a space (workspace admin).

V23's three additive booleans (author / promoter / admin) were folded back into this value by V29 with the precedence admin → workspace_admin, else promoter → promoter, else author → author, else viewer; the database CHECK (chk_workspace_member_role, chk_workspace_invitation_role) keeps the set closed.

8A. ApiKeyKind — what an API key IS

Source: Auth §7.7 Used by: auth, web, mcp-server, persistence (api_keys.kind).

A kind answers "where may this credential be presented?"; its ROLE (§8D, or the chosen member role for the mcp key) answers "what may it do there?". Each kind carries exactly one role — the database CHECK (chk_api_keys_role) makes it a fact. The wire form is the lowercase name.

A server key authenticates nothing outside the promotion routes. Presented as an ordinary DP-API-Key it is refused on every route — REST, htmx partials, /mcp and every UI page — with endpoint.key_kind_refused. Same rule as the endpoint kind, different family.

An endpoint key with no binding on any ancestor of the path it presents at authorises nothing. The absence of a binding is never a fall-through (since #215 B3 an unbound path serves no key at all); if it were, publishing a new endpoint would silently widen every existing endpoint key's reach at the moment of publication.

A dashboard key with no binding on any ancestor of the dashboard's name serves nothing (L5, R-EP2 verbatim): an unbound key, a key bound elsewhere and a key of another workspace all get the dashboard family's ordinary 404, and a deeper binding REPLACES an inherited one.

8D. KeyRole — the role a key carries

Source: Auth §7.5 and the key-role columns of the §7.6 catalog; the permissions and keys record §3.2 Used by: auth (KeyRole, RolePermissions.of(KeyRole), AuthenticatedPrincipal.keyRole), persistence (api_keys.role, V34, CHECK chk_api_keys_role), the REST role field of key creation (rest-api §16.1), the Keys page's Role column.

Pre-created and fixed: the three member roles are the ONLY roles an mcp key can carry (A15 — viewer is never a key role; B1 — super_admin is neither offerable nor acceptable), and no key role holds workspace admin or super admin AUTHORITY over people (PK3). snake_case everywhere (A5); the UI prints it with a space (api caller, workspace admin).

9. NodeStatus — per-node execution outcome

Source: DAG Executor §7 Used by: dag-executor (node_stats), rest-api (response envelope).

10. ExecutionStatus — whole-pipeline execution outcome

Source: REST API §6.4, DAG Executor §5 Used by: rest-api, dag-executor, mcp-server, persistence (pipeline_executions.status).

Reserved for future: PARTIAL (partial-result mode where some nodes succeeded but a non-critical path failed — see ROADMAP).

Declaration reality (2026-08-10). Declared in the dag module, for the same layering reason SseEventType is (§11): web implements rest-api at layer 5 and depends on dag at layer 3, never the reverse (module-structure §4.2). The executor is what produces the status and what writes pipeline_executions.status, so the enum lives at the lowest layer that needs it and web consumes it. This document, rest-api and metadata-db remain the wire authorities — the declaration site is an implementation consequence, not a change of ownership.

11. SseEventType — pipeline execution event types

Source: REST API §6.4, DAG Executor §10 Used by: rest-api (SSE endpoint), dag-executor (event emitter), mcp-server (event forwarding).

Order guarantees: see REST API §6.5.

Reserved for future: data_chunk (streaming row chunks for incremental processing — see ROADMAP).

12. ResultDelivery — REMOVED (v1.1)

Removed 2026-08-07 (SPEC-REVIEW-2026-08, decision D9). The inline-vs-claim-check split no longer exists: every caller result is stored in Redis and data_ready always carries schema + inline first page + result_url cursor. See REST API §7. Section number retained so later sections keep their numbering.

13. ResultFormat — wire format for result data

Source: REST API §7 Used by: rest-api, mcp-server.

14. SslMode — datasource TLS mode

Source: Datasources §5 Used by: datasources (PG-idiomatic; analogous config for other dialects).

15. AuthAuditEvent — auth audit log events

Source: Auth §10.1 Used by: auth, observability.

Password and lockout events exist only for the optional local accounts (Auth §5A); an OIDC-only deployment never writes them. No event in this table ever carries credential material.

Datasource audit events (same audit_log table, defined in Datasources §7.4):

Promotion audit events (same audit_log table, defined in Versioning §10):

MCP audit events (same audit_log table, defined in MCP §14):

Version lifecycle audit events (same audit_log table, defined in Versioning §3; emitted by the 101 REST verbs, all session-only — an API key cannot produce one):

Learned-semantics audit events (same audit_log table, defined in the learned-semantic-layer design record §9; emitted by SemanticsService for the semantics_record / semantics_retire MCP tools — 118):

Mail audit events (same audit_log table, defined in Auth §5A.8; emitted by MailNotifier off the request thread, after the transport answered — 137):

Schedule audit events (same audit_log table; emitted by the schedule REST routes, REST API §20, all session-only in slice 1 — #9). A person's acts only: what a schedule does when it FIRES is its runs' trail (Metadata DB §4.24), not an audit row, because nobody acted.

Dashboard audit events (same audit_log table; emitted by the dashboard runtime's refresh, Dashboards §5, #10 L2). ONE row per refresh, AWAITED (audit rows are authorization inputs — never the fire-and-forget path) and written at the refresh's END whatever its ending, the client gone or the process stopping included. user_id is the refreshing person. details carries refresh_id, dashboard_id, dashboard_version, workspace_id, instance_id, scope, status (a RefreshStatus), targets (name → outcome) and execution_ids — never a selection, a row or a driver message. A refresh refused at admission (429) writes no row and so no event.

16. Error Code Domains (prefix catalog)

Source: Pipeline Contract §13 — the ONLY catalog of concrete error codes. This section registers domains; deliberately no code list here, so there is exactly one place a code can drift from. Used by: every spec that defines error codes.

Error codes follow {domain}.{entity}.{failure} — three segments, all lowercase snake_case, dot-separated, ASCII. Two-segment codes exist only where the domain has no entity dimension (datasource.in_use, datasource.driver_not_loaded, datasource.not_found, datasource.lease_in_transaction, datasource.table_not_found, datasource.table_forbidden, template.not_found, the bare template.* block and citation codes (template.contract_invalid, …, template.implements_unresolved — about the version's own content, 7b/7e), rate_limit.exceeded, rate_limit.unavailable, every semantics.* code — a learned fact has no sub-entity — mcp.doc_not_found, the schedule's own states: schedule.not_found, schedule.name_taken, schedule.revision_conflict, schedule.blocked, schedule.not_blocked, and parameter.not_found and parameter.in_use (#320) — a parameter set is the entity, and "a dashboard pins it" is a state of the set, the template.in_use shape; visualization.not_found and dashboard.not_found likewise; and the request cap's request.body_too_large — the body itself is the refused thing). Additive-only — never reused, never renamed.

Removed 2026-08-07 (D5): the auth.rate_limit.* domain (folded into rate_limit.exceeded), the template.import.* domain (folded into template.validation.*), the idempotency_key.* spelling (now idempotency.*), and result.claim_check_expired (now result.expired under the D9 result model).

17. HTTP Status Code Conventions

Source: REST API §2 Used by: every spec that defines HTTP behavior.

18. ExecutionTrigger — how execution was initiated

Source: REST API §10.2 Used by: rest-api, mcp-server, persistence.

Declaration reality (2026-08-10). Declared in the dag module, for the same layering reason as ExecutionStatus (§10) and SseEventType (§11): the executor owns the execution repository that persists pipeline_executions.trigger, and it sits below web. This document, rest-api and metadata-db remain the wire authorities.

18A. ExecutedByKeyKind — which kind of credential started an execution

Source: metadata-db §4.6 (pipeline_executions.executed_by_key_kind, V30), REST API §10.2 Used by: dag (ExecutedByKeyKind, the own-runs predicate), rest-api, mcp-server.

Roles design D11 (2026-09-20). executed_by names the user a run belongs to — the session's user, or a key's OWNER. This value says which KIND of credential started it when a key did; null means a signed-in session. The values mirror ApiKeyKind's wire names, but the enum is dag's own: the executor does not depend on auth and does not care what a key IS, only how the run is attributed.

The CHECK (chk_executions_executed_by_key_kind) admits these four and NULL. V30 backfilled ENDPOINT-triggered rows to endpoint and MCP rows to user; REST and UI rows stayed NULL (a REST run may have been a key or a cookie, and NULL reads as "a person's run", which is what those rows meant).

19. LearnedFactKind — what a learned fact is about

Source: Learned semantic layer design §4 (the ruling); the chk_learned_facts_kind CHECK of Metadata DB §4.18 is the enforcing copy. Used by: datasources (LearnedFactKind, the recorder), mcp-server (semantics_record's kind enum, derived), the introspection enrichment, the UI.

Closed. No type, nullable, key, comment, partition or row_count kind exists and none will (D-S2: nothing JDBC metadata already provides is stored — introspection stays the source for those and is what facts are checked against). Each kind belongs to exactly one scope; the database states the same rule in chk_learned_facts_kind_scope. Three sources — this table, the CHECK's list, the Kotlin enum — are held to one truth by LearnedFactKindSpecDriftTest.

Trust (the companion state, design §5 — not an enum a caller supplies): asserted (no evidence — or a definition/exclusion/preference, a choice, whatever it carries; C.2 2026-09-13) → observed (evidence ran at record time, data-kind facts only) → verified (a human confirmed); the mechanical demotions needs_review (the table's column set changed around a still-resolving ref) and stale (a referenced column or table no longer exists); and retired (explicit, with a reason — never a delete). Written as the chk_learned_facts_trust CHECK.

20. CheckRunVerdict — a release check's outcome (140)

Source: pipeline-contract §13.17; the chk_pipeline_check_runs_verdict CHECK of Metadata DB §4.20 is the enforcing copy; the Kotlin enum is CheckRunVerdict (pipeline-contract ReleaseCheckGate.kt). Used by: pipeline-contract (the release gate), application (the check runner), mcp-server (pipelines_run_checks), rest-api (§5.16), the UI.

Closed. A release refuses on fail OR error alike (versioning §5.3 precondition 4) — the distinction exists for the human reading the dialog, not for the gate.

21. CheckRunVia — who commissioned a check run (140)

Source: pipeline-contract §13.17; the chk_pipeline_check_runs_via CHECK of Metadata DB §4.20; the Kotlin enum is CheckRunVia. Used by: application (the check runner), mcp-server, rest-api, the UI.

Closed. The run rows are append-only; via is the record of WHICH surface commissioned each one.

22. MissedRunPolicy — what a schedule does about occurrences it missed (#9)

Source: Scheduler §4; the chk_schedules_missed_run_policy CHECK of Metadata DB §4.22; the Kotlin enum is MissedRunPolicy (scheduler ScheduleModel.kt). Used by: scheduler, rest-api §20.

Closed. Paused and blocked time is never "missed" under either policy — resume and unblock recompute from now.

23. RunOrigin — why a schedule run exists (#9)

Source: Metadata DB §4.23 (chk_schedule_runs_origin); the Kotlin enum is RunOrigin. Used by: scheduler, rest-api §20.

24. RunState — a schedule run's state (#9)

Source: Scheduler §5 (states and every reason); Metadata DB §4.23 (chk_schedule_runs_state); the Kotlin enum is RunState. Used by: scheduler, web (the pipeline executor maps execution terminals onto it), rest-api §20.

queued, starting and running are ACTIVE — at most one per schedule. The run's reason column carries the why; the reasons are strings the scheduler and the executor define (Scheduler §5), not a closed enum.

25. TrailKind — one row of a run's trail (#9)

Source: Metadata DB §4.24 (chk_schedule_run_events_kind); the Kotlin enum is TrailKind. Used by: scheduler, rest-api §20.11.

Append-only. A trail row is never changed or removed; the run row is the projection of its latest row.

26. ParameterCardinality — how many values one parameter carries (#194)

Source: Pipeline Contract §6.1/§6.2 (a pipeline parameter's optional cardinality) and the parameter-engine record §3.2 (a parameter set's); the Kotlin enum is ParameterCardinality (typesystem, ParameterDeclaration.kt). Used by: pipeline-contract, the parameter engine (#194's later lanes).

Closed. Any other value is refused where it arrives (cardinality_unsupported on a pipeline).

27. ParameterKind — the two kinds of control (#194)

Source: the parameter-engine record §3.2, P23; the Kotlin enum is ParameterKind (parameters, ParameterSetModel.kt). Used by: the parameter engine; its REST/MCP surfaces (lane D).

Closed. Any other value is parameter.validation.kind_invalid. A third, caller-supplied FIXED kind was considered and rejected by the owner (the record's §13).

28. SelectorSourceKind — where a parameter's options or initial value come from (#194)

Source: the parameter-engine record §3.3/§3.4; the Kotlin enum is SelectorSourceKind (parameters), DERIVED from which of source's keys is present — it is never a wire key itself. Used by: the parameter engine.

Closed. A source stating both or neither is parameter.validation.source_ambiguous; constants on an INPUT is source_not_allowed.

29. PresentationControl — how a renderer may show a parameter (#194)

Source: the parameter-engine record §3.7, P23c; the Kotlin enum is PresentationControl (parameters). Which values a parameter may name depends on kind × cardinality × type — the record's §3.7 table; the first allowed value of a row is the derived default a renderer receives when none is stated. Used by: the parameter engine (validation and echo only — nothing reads it for meaning, binding or evaluation).

Closed but additive — a new value is a change-log row, never a bump. An unknown value is parameter.validation.presentation_invalid; a known one outside its row is control_not_applicable.

30. NumericFormatKind — a numeric parameter's display format (#194)

Source: the parameter-engine record §3.7; the Kotlin enum is NumericFormatKind (parameters), the kind of a numeric presentation.format. A temporal type's format is a pattern instead; STRING/BOOLEAN/BINARY take none. Used by: the parameter engine (validation and echo only).

Closed. Any other value — or a kind on a non-numeric type — is parameter.validation.format_invalid.

31. RendererKind — what a visualization's configuration targets (#10)

Source: the dashboard implementation spec §3.1 (D4, D12, D13); the Kotlin enum is RendererKind (visualization, VisualizationModel.kt), renderer.kind of a visualization (Dashboards §2.1). Used by: the visualization module; the client runtime's adapters (L3).

Closed. An unknown value — and, in round one, html or svg — is visualization.validation.renderer_unsupported.

32. AssertionKind — what a visualization test case asserts (#10)

Source: the spec's §3.1 tests.cases[].assertions (D34, D56 (a)); the Kotlin enum is AssertionKind (visualization). Used by: the visualization module; the agent's test session (L4).

Closed. An unknown kind, a missing argument or an argument the kind does not take is visualization.validation.test_case_invalid.

33. TestRunStatus — a visualization test run's state (#10)

Source: the spec's §2.1 and §11.2; the CHECK of visualization_test_runs.status (V42, metadata-db §4.32). The Kotlin enum is TestRunStatus (visualization); the tests lane (L4) writes the rows. Used by: the release gate (L4), the test-session routes.

Closed. The database's chk_visualization_test_runs_status refuses any other value.

34. DashboardObjectType — the type of a dashboard object (#10)

Source: the spec's §3.2 (D15, D17); the Kotlin enum is DashboardObjectType (visualization). Every object carries its type, and each list admits exactly one. Used by: the visualization module; the runtime's object-directed events (L2, the spec's §8.3).

Closed. A missing type, or one that is not its list's, is dashboard.validation.body_invalid (details.reason = wrong_object_type).

35. ActionScope — what a refresh action targets (#10)

Source: D55 (superseding R11/D18's empty-list shorthand); the Kotlin enum is ActionScope (visualization). Used by: the visualization module; the runtime's refresh request (L2).

Closed. Any other value is dashboard.validation.body_invalid; targets with no list, or all with one, is dashboard.validation.empty_targets.

36. StateSetting — a parameter-state override (#10)

Source: D20 and the record's §4.4; the Kotlin enum is StateSetting (visualization), each dimension (visible, enabled) of a parameter_state override. Used by: the visualization module; the runtime's parameter operation (L2).

Closed. Any other value is dashboard.validation.body_invalid.

37. LayoutPosition — a layout region (#10)

Source: R6 and the record's §7.4; the Kotlin enum is LayoutPosition (visualization) — layout.parameter_set.position and a parameter placement's region. Used by: the visualization module; the client runtime's layout (L3).

Closed. Any other value is dashboard.validation.body_invalid.

38. RefreshStatus — a dashboard refresh's state (#10)

Source: Dashboards §5, the implementation spec's §2.2; the Kotlin enum is RefreshStatus (visualization) — the CHECK of dashboard_refreshes.status (V43) and refresh_completed.status on the stream. Used by: the visualization module, the dashboard runtime, rest-api §23.3, metadata-db §4.34.

Closed. A refresh refused at admission has NO status: it writes no row.

39. EvaluationCaller — who ran a parameter-set evaluation (#376)

Source: the parameter-set workspace spec §2.1 (R2) and the owner's §11.10 ruling; the Kotlin enum is EvaluationCaller (parameters) — the CHECK of parameter_evaluations.caller (V48). Every evaluate names one in its REQUIRED EvaluationAttempt. Used by: the parameter engine's recorder, the History tab's Caller column, metadata-db §4.37.

Closed. The value is code-chosen per call site, never read from a request.

40. ParameterEvaluationStatus — a parameter-set evaluation record's state (#376)

Source: the workspace spec §2.1 with the owner's §11.7 ruling (ABORTED); the Kotlin enum is ParameterEvaluationStatus (parameters) — the CHECK of parameter_evaluations.status (V48). Its four terminal words are EvaluationOutcome's (#375). Used by: the recorder, the stale sweep (metadata-db §8.5), the History tab, metadata-db §4.37.

Closed. A request refused before admission (parameter.evaluate.unknown_parameter) has NO status: it writes no row.

41. QueryAttemptOutcome — one statement attempt's outcome (#376)

Source: the workspace spec §2.2 with the owner's §11.7 ruling (ABORTED); the Kotlin enum is QueryAttemptOutcome (parameters) — the CHECK of parameter_evaluation_queries.outcome (V48). NULL while the statement is in flight. Used by: the recorder, the record detail's attempt table, metadata-db §4.38.

Closed. A constants selector and a plain-default input run no statement and have no row.

Cross-Reference: Where Each Enum Is Authored

Validation Discipline

When a spec or code change introduces or renames an enum value:

1. Update this document first. This is the source of truth.
2. Search all specs for the old spelling — grep for the value across docs/*.md.
3. Search the codebase — grep for the value across modules/**/*.kt.
4. Bump the spec's schema_version if the change is non-additive (per the spec's stability promise).
5. Document the change in the spec's Change Log appendix and in ROADMAP if it was previously tracked there.
6. Run scripts/docs-audit.sh — it mechanically enforces steps 2's doc sweep (cross-references, error codes, config keys, forbidden legacy spellings, cited test files) and must exit 0 before the change lands.

This document itself is additive-only — values are never removed (only marked deprecated). The authoring spec governs its own stability promise; this doc tracks usage.

42. NotificationEvent — a schedule's notification choices (#442)

Stored in schedules.notification_events (Metadata DB §4.22), serialized in declaration order by REST §20. These settings select which transitions mail is sent for (#442 part b): each outcome of §43 belongs to one event (Scheduler §2.3).

No mail for skipped ticks or pause/resume. Empty recipients means off; recipient addresses are never audit fields.

43. NotificationOutcome — what one notice reports (#442b)

Stored in schedule_notification_events.outcome (Metadata DB §4.39), the notice of a delivery in REST §20.11, and the trail rows' reason for the notification kinds (§25). Each outcome belongs to one §42 event — the schedule's choice of that event decides whether the notice is written — and fixes the subject's state words; the subject is <schedule name> — <state words>, with control characters stripped from the name.

No notice for queued, starting or skipped. One notice per (run, outcome) — a duplicate callback writes none.

44. DeliveryState — one recipient's copy of a notice (#442b)

Stored in schedule_notification_deliveries.state (Metadata DB §4.40), shown in REST §20.11's deliveries. Never "delivered": the product knows only what the relay said.

A resend (REST §20.13) returns a failed or uncertain delivery to pending under the same Message-ID; nothing else moves a settled delivery.

last_error_code — sanitized, never transport text or an address:

Appendix A: Change Log