# Audita Internal Pipeline

## Scope

This document describes processing collaborators and state transitions. External
input definitions belong to the [input-file contract](../integrations/transcript-glossary-files.md),
settings to [configuration](../config.md), and serialized results to the
[output-file contract](../integrations/output-files.md).

## Inputs

Pipeline inputs are:
- effective config (`internal/core/config`);
- transcript JSON (`internal/core/schema`);
- glossary YAML (`internal/core/schema`).

## Pipeline Phases

1. **Input loading:** CLI filesystem adapters read inputs; schema parsing produces
   source transcript and glossary objects. Source segments are converted to the
   canonical transcript shape before normalization.
2. **Normalization:** the normalizer sorts and merges segments using its configured
   time/token rules, reassigns IDs, and produces summary counters.
3. **Chunking:** the chunker partitions the normalized transcript and returns
   sections and token estimates, or fails when constraints are impossible.
4. **Proposal generation:** the runner executes configured module instances in
   sequence. Sections can generate proposals concurrently; results are collected
   for deterministic indexing.
5. **Validation:** deterministic validators run before LLM-backed validators.
   LLM validation is batched by prompt budget; candidate decisions feed application.
6. **Application:** `internal/framework/proposals` clones transcript state and
   applies approved proposals in index order through replacement-policy checks.
7. **Serialization and reporting:** the CLI encodes the final transcript, maps
   runner output into reports, writes artifacts, and delegates retention to
   diagnostics. See [report assembly](diagnostics-reporting.md).

## Runner Outputs

`runner.Run` returns:
- final transcript;
- per-module results;
- utilization diagnostics.

CLI/reporting then map this into process report and diagnostics artifacts.

## Failure Behavior

CLI orchestration labels failures at the phase boundary. Runner execution failures
can return completed or partial module results, which report assembly preserves.
[Report fields](../integrations/output-files.md#process-report) define how consumers
see these outcomes; [CLI semantics](../cli.md#process-output-and-exit-behavior)
define streams and exits. Diagnostic write failures do not always abort processing.

## Ordering and State

The runner mutates its working transcript between module instances, after collecting
section results and validating proposals. Proposal indexes follow section order;
reports are derived from actual run results. Global requirements are owned by the
[architecture policy](../policy/architecture.md#correction-and-concurrency-invariants).

## Key Tests

- `internal/framework/runner/runner_test.go`
- `internal/framework/proposal_generation/*_test.go`
- `internal/cli/run_test.go`
- `cmd/audita/main_integration_test.go`