# Faultprint Assessment Operating Model 001

## Purpose

This defines how a submitted corpus becomes a bounded Faultprint assessment without turning into recommendations, predictions, or unsupported benchmark claims.

## Workflow

### 1_intake

Capture corpus, institution context, sector, and intended use.

Quality gate: Reject or caveat unsupported document context; no finding can be made from uncited material.

### 2_corpus_preparation

Convert documents into reviewable corpus units with stable identifiers.

Quality gate: Every cited passage must have document name, section/page if available, and retrieval date.

### 3_module_screening

Screen corpus against ready and pilot pathology modules.

Quality gate: Only ready modules can produce standard findings; pilot modules require stronger source support.

### 4_extraction

Create source-anchored findings, counter-signals, boundaries, and falsification tests.

Quality gate: No finding without source anchor, boundary, and falsification evidence.

### 5_calibration

Compare findings against known operating/postmortem library rows.

Quality gate: Comparable-case language must remain bounded and non-predictive.

### 6_report_generation

Produce executive assessment and evidence ledger.

Quality gate: No recommendations, predictions, illegality claims, or build/process language.

### 7_review

Human review for falsifiability, source traceability, and claim discipline.

Quality gate: Client-facing output must pass source, boundary, and prohibited-language checks.

## Report Schema

- Corpus position
- Structural-condition findings
- Evidence ledger
- Counter-signals and mitigants
- Falsification evidence
- Boundaries
- Comparable public cases

## Required Finding Fields

- finding_id
- module
- condition_name
- source_anchor
- source_location
- why_it_matters
- boundary
- falsification_evidence
- counter_signals
- comparable_public_cases

## Prohibited Fields

- recommendation
- prediction
- failure_score_claim
- illegality_claim

## Product Decision

The assessment product can be operated manually first, with the workflow and schema acting as the engine contract. Software should automate intake, source anchoring, module screening, and report assembly only after the contract is stable.