10. Configuration and Modes

Configuration parameters affect validation and runtime behavior for a given execution.

10.1 Pipeline Stages

The default execution pipeline is defined in Chapter 9. Configuration may select tooling inputs or policy switches for that pipeline, but it does not redefine the pipeline stages.

Input scope:

1. CLI pipeline accepts one entry source for a single run.
2. Repeatable CLI input paths are a batch surface; each input is an independent run.
3. Frontend resolution performs source load, parse, include dependency loading, and optional library-root import resolution before compile.
4. CLI entry behavior follows the Chapter 9 entry-source script and compatibility fallback rules.

10.2 Inventory Check

Inventory check is an optional final-result reconciliation, not an execution mode. For minor-version API compatibility, tooling retains the inventory_check / --inventory-check public name and may attach an external inventory snapshot for comparison with the run-scoped reagent-consumption record.

Rules:

1. Runtime binding, insufficient-material failure, and conservation behavior are invariant whether or not an external inventory snapshot is supplied.
2. Reconciliation runs after runtime material accounting and adds an inventory result alongside runtime success and the derived run report.
3. External shortage is reported by the inventory result and does not change runtime success.
4. Reconciliation is read-only with respect to runtime and inventory inputs.
5. Core execution has no mode that auto-provisions or tops up material.

10.3 Runtime Error Policy

Runtime error policy controls execution after step failure.

Supported policies:

1. fail-fast (abort): stop dispatching new steps after failure; remaining pending steps become skipped.
2. continue: keep dispatching dependency-satisfied steps while accumulating diagnostics.

Rules:

1. Default policy is fail-fast.
2. Under fail-fast, downstream steps of failed steps must not execute.
3. CLI exposes the default abort/fail-fast behavior only; continue remains an internal/programmatic runtime option rather than a first-class CLI flag.

10.4 Reference Reuse Policy (include)

Runtime implements reference-group reuse for expanded protocol-reference include blocks.

Mechanism:

1. Cache key is derived from (ref_protocol, call_path).
2. Input signature is derived from (ref_protocol, call_path, expanded steps' (op,args)).
3. Signature match reuses the group without driver execution.
4. Cache miss/signature change reruns and updates cache.

Rules:

1. Default policy is auto (signature-match reuse).
2. Force-reuse/force-rerun are runtime internal policies and not language-level syntax.

10.5 Entry Selection Scope

Configuration surface:

1. CLI input paths select entry sources and batch order.
2. Entry-source script and compatibility fallback behavior is defined in Chapter 9.

Entry selection contract:

1. Script entry selection follows entry-source top-level executable statements.
2. CLI input order defines batch item order.
3. Unknown protocol references are handled by plan diagnostics defined in Chapter 8.

10.6 Driver and Failure Injection

The runtime is parameterized by a driver interface.

Tooling may support deterministic failure injection for testing:

1. A stub driver may mark specific operations as failed.
2. Failure injection is tooling behavior, not language semantics.

10.7 Global Material State

Configuration may provide initial material state as execution input. The material-state model and its invariant checks are defined in Chapter 7, and execution/replay artifacts are defined in Chapter 9. External inventory configuration affects only the optional reconciliation result.

10.8 Material Content Classification Policy

Material-content classification modes use the classification vocabulary and constructor field contract defined in Chapter 6. Diagnostic placement is defined in Chapter 8.

Strict material-content validation:

1. content_whitelist_mode = strict: material content_kind values are checked against the Chapter 6 canonical whitelist.
2. content_type_policy = required: material content_type values must be present and satisfy the Chapter 6 closed canonical table.

Rules:

1. Conformance claims assume strict material content_kind whitelist enforcement.
2. Conformance claims assume required material content_type enforcement.
3. Warning-only or legacy-auto-normalizing material-content classification profiles are compatibility behavior, not the strict canonical conformance baseline.
4. Compatibility profiles may accept older custom/unknown type strings, emit a warning, and normalize them to canonical values or the appropriate other_* fallback.