bbchops/transcription
1
0
Fork 0
generated from john/python-template
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

gpt-5.3-codex review phase 1 - Flatten the documentation
Quality Gate / gate (push) Successful in 33s
Details

Browse Source
This commit is contained in:
Jim Lancaster
2026-08-19 14:54:24 -05:00
parent 2c26177d0c
commit 5404224079
32 changed files with 358 additions and 4467 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/invariant/ai_evidence_and_provenance.md
+9 -9
View File
@@ -10,7 +10,7 @@ The application exists to preserve historical source material and produce useful
The application distinguishes five kinds of information:
1. **Source evidence**: the original uploaded media and the facts needed to identify and verify it.
1. **Source evidence**: the canonical stored media used for processing and the facts needed to identify and verify it.
2. **Execution specification**: the frozen instructions, parameters, source identity, and software context for one processing attempt.
3. **Transport evidence**: the response received at the application/provider boundary, including safe protocol metadata.
4. **Normalized data**: selected fields extracted for search, display, accounting, and workflow behavior.
@@ -20,12 +20,12 @@ Normalized data and derived artifacts never replace source or transport evidence
## 3. Core Invariants
### 3.1 Original Source Preservation
### 3.1 Canonical Source Preservation
1. The original uploaded bytes are the primary evidence and must be preserved without transformation.
2. Each source must have a cryptographic content digest, byte size, and stable identity.
3. Processing may use transformed derivatives, but those derivatives must not overwrite the original.
4. A derivative used for processing must record its relationship to the original, its transformation, and its own digest.
1. Each source must have one canonical stored byte stream used for processing and provenance.
2. Canonical storage may apply deterministic ingest normalization before persistence.
3. Canonical stored bytes must have a cryptographic content digest, byte size, and stable identity.
4. Post-ingest processing derivatives must not overwrite canonical stored bytes.
5. Moving or renaming a stored file must not change its evidence identity.
### 3.2 Append-Only Processing History
@@ -45,7 +45,7 @@ Each execution must preserve enough information to understand what the applicati
3. Prompt asset name and content digest when a prompt asset is used.
4. Every explicitly supplied generation or processing parameter.
5. Whether an optional parameter was explicitly set or omitted.
6. Source and derivative digests, media type, dimensions or page geometry when known, and page identity.
6. Canonical source digest (and derivative digests when used), media type, dimensions or page geometry when known, and page identity.
7. A secret-safe representation of the request structure.
8. Application, provider-adapter, and client-library versions sufficient to interpret the execution.
@@ -108,7 +108,7 @@ Provenance supports explanation, comparison, and best-effort reproduction; it do
Identical requests may produce different results because of model updates, provider routing, nondeterministic computation, undocumented defaults, safety systems, or retired endpoints. The application must preserve whether a parameter was omitted rather than pretending to know the provider default used at that time.
Likewise, preserving a general vision-model response does not create OCR coordinates that were never returned. Future coordinate extraction remains possible because the original source evidence is preserved and can be processed again by a suitable system.
Likewise, preserving a general vision-model response does not create OCR coordinates that were never returned. Future coordinate extraction remains possible because canonical source evidence is preserved and can be processed again by a suitable system.
## 5. Model Evaluation Policy
@@ -127,7 +127,7 @@ Benchmark material containing family records remains private application data un
## 6. Ownership and Change Policy
1. Versioned architecture, schema, scope, and implementation documents define how a release satisfies this invariant.
1. Canonical V4 architecture, schema, requirements, and error-policy documents define how current behavior satisfies this invariant.
2. Provider adapters own the capture of provider-boundary evidence.
3. Services own validation, persistence, retention, and export behavior.
4. UI pages may inspect evidence through service contracts but do not define evidence semantics.