# Evidence Qualification Protocol — FULL RESEARCH CORPUS (share wrapper)
Abbreviation: eqp
Version: v0.1.0
Bundle name: llm-full-docs-eqp
Upstream artifact: .agents/llms-full-eqp-v0.1.0.txt
Generated: unspecified
========================================================================

# EVIDENCE QUALIFICATION PROTOCOL (EQP): CONSOLIDATED SPECIFICATION & RESEARCH CORPUS
Version: v0.1.0 (2026-09-29) | Modules: 19 | Total Lines: 1,429

TABLE OF CONTENTS & SUBSYSTEM SUMMARY:
  - Normative Specifications & Protocol Documents: 10 files
  - Machine Schemas & Definitions: 4 files
  - Examples & Test Vectors: 4 files
  - Other Modules: 1 files

========================================================================

========================================================================
## FILE: .agents/AGENTS.md
========================================================================

# Evidence Qualification Protocol (EQP) Agent Operating Contract (`.agents/AGENTS.md`)

This document defines the system doctrine, operational guidelines, status honesty rules, hierarchy of authority, verification gates, and engineering standards governing AI agents and human collaborators working on **Evidence Qualification Protocol (EQP)**.

---

## 1. System Taxonomy & Canonical Naming

Agents must consistently enforce official naming across code, documentation, and commit messages:

```text
Evidence Qualification Protocol (EQP)
  ├── 01-EQP-SPECIFICATION.md (Normative Protocol Specification)
  ├── 02-FORMAL-MODEL.md (Formal Objects, Relations & Decision Logic)
  ├── 03-PROOF-AND-FALSIFICATION.md (Proof & Falsification Rules)
  ├── 04-CONFORMANCE.md (Conformance Levels & Test Vectors)
  ├── 05-PROTOCOL-RELATIONSHIPS.md (Inter-Protocol Boundaries)
  ├── 06-PROFILES.md & 07-ADOPTION.md (Qualification Profiles & Authority Mapping)
  └── Machine Schemas & Test Vectors (schemas/, examples/, conformance/)
```

---

## 2. Epistemic Integrity & "Status Honesty" Rules

Agents must adhere strictly to the **Four-Tier Claim Taxonomy**:

$$\text{Documented} \neq \text{Implemented} \neq \text{Tested} \neq \text{Empirically Validated}$$

1. **Never Conflate Maturity Levels**:
   - A claim documented in an EQP spec is *documented*, not *implemented*.
   - A test vector that passes schema validation is *tested*, not *empirically validated*. State the weaker claim when in doubt.
2. **Permanent Retention of Negative Results**:
   - Disproven evidence schemas, invalid qualification paths, or rejected candidate assertions must be recorded permanently.
3. **Core Invariant**:
   $$\text{Candidate} \neq \text{Claim} \neq \text{Evidence} \neq \text{Evaluation} \neq \text{Qualification} \neq \text{Promotion}$$

---

## 3. Hierarchy of Authority (`01-EQP-SPECIFICATION.md`)

When documentation, code, generated artifacts, or AI outputs conflict, resolve in strict canonical order:

$$\text{Normative Protocol (01-EQP)} \to \text{Formal Model (02-FORMAL)} \to \text{Machine Schemas (schemas/)} \to \text{Test Vectors & Examples} \to \text{Generated Artifacts}$$

- **Rule**: Code or generated artifacts **never** silently alter normative protocol specifications.

---

## 4. Verification Gates & Execution Standard

Before proposing code or spec modifications, agents must run the context exporter script:

```bash
python3 scripts/gen-llms.py
```

### Verification Rules

- **Schema Conformance**: Every machine-readable JSON schema under `schemas/` must validate against example instances.
- **Git Voice**: Use clean, human engineering prose. No AI attribution trailers (`Co-Authored-By`, `Generated by AI`), no tool session IDs in tracked commits or docs.

---

## 5. Agent-First Publishing Architecture (`.agents/llms-full-eqp-v0.1.0.txt`)

1. **Single-Pass Deterministic Context (`llms-full-eqp-v0.1.0.txt`)**:
   - `.agents/llms-full-eqp-v0.1.0.txt` is an auto-generated, single-file concatenation of all protocol specs, schemas, and test matrices.
   - Reading `llms-full-eqp-v0.1.0.txt` provides AI agents with instant, zero-search access to all EQP specifications without multi-step file discovery latency.
2. **Automated Downstream Generation**:
   - Generated via `python3 scripts/gen-llms.py`.

========================================================================
## SUBSYSTEM: NORMATIVE SPECIFICATIONS & PROTOCOL DOCUMENTS (10 files)
========================================================================

--- FILE: 00-README.md (80 lines, 2.9 KiB) ---
# Evidence Qualification Protocol (EQP)

**Identifier:** `eqp:protocol/evidence-qualification`  
**Version:** `0.1.0`  
**Status:** Normative Candidate  
**Scope:** Project-independent evidence qualification  

## Purpose

The Evidence Qualification Protocol (EQP) defines a project-independent method for determining what claims a declared body of evidence justifies about an identified candidate in a declared context.

EQP governs:

- candidate identity;
- claim identity and scope;
- qualification context;
- evidence obligations;
- evidence provenance, applicability, freshness, and validity;
- evaluator identity, capability, and independence requirements;
- evidence invalidation and inheritance;
- limitations, uncertainty, exceptions, and negative results;
- qualification disposition;
- qualification attestations and receipts;
- conformance and falsification of qualification claims.

EQP does **not** itself authorize promotion, deployment, publication, release, adoption, spending, or any other protected action. Promotion authority consumes EQP results under the governing project, domain, or institutional policy.

## Core question

> Given this exact candidate, this exact claim, this exact context, and this exact evidence, what is justified?

## Core invariant

```text
Candidate != Claim != Evidence != Evaluation != Qualification != Promotion
```

A candidate may be qualified for one claim and unqualified for another.

## Canonical flow

```text
baseline
  -> candidate
  -> semantic delta
  -> claim set
  -> qualification profile
  -> evidence obligations
  -> evidence collection
  -> evaluation
  -> evidence validity / invalidation
  -> qualification
  -> qualification attestation
  -> external promotion decision
  -> optional post-promotion qualification
```

## Package

1. `01-EQP-SPECIFICATION.md` — normative protocol.
2. `02-FORMAL-MODEL.md` — formal objects, relations, invariants, and decision semantics.
3. `03-PROOF-AND-FALSIFICATION.md` — what can be proved, how, and what would falsify each claim.
4. `04-CONFORMANCE.md` — protocol conformance levels and mandatory test vectors.
5. `05-PROTOCOL-RELATIONSHIPS.md` — boundaries with FCI, ICP, IEPE, PDP, SES, and domain protocols.
6. `06-PROFILES.md` — release, research, protocol, model, dataset, and document profiles.
7. `07-ADOPTION.md` — project adoption and authority mapping.
8. `08-REFERENCE.md` — compact operator reference.
9. `schemas/` — machine-readable candidate, evidence, qualification profile, and attestation schemas.
10. `examples/` — positive and negative examples.
11. `conformance/PROOF_MATRIX.md` — claim-to-test matrix.

## Status honesty

EQP distinguishes at minimum:

```text
Documented != Implemented != Tested != Empirically Validated
```

A structurally conforming EQP implementation proves only the declared protocol behavior. It does not prove that a domain claim is true, that evidence is sufficient in all contexts, or that EQP improves outcomes without empirical study.

--- FILE: 01-EQP-SPECIFICATION.md (414 lines, 11.2 KiB) ---
# Evidence Qualification Protocol — Specification v0.1.0

## 0. Normative status

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, **SHOULD NOT**, and **MAY** are normative.

EQP is a composition protocol. It does not replace domain-specific test frameworks, scientific methods, policy engines, release systems, issue trackers, interaction contracts, or promotion authorities. It binds their evidence into an explicit qualification decision.

## 1. Normative definition

An **Evidence Qualification** is a bounded determination of what one or more evidence records justify claiming about a specific candidate under a declared qualification profile and context.

A qualification is defined as:

```text
Q = <C, K, X, P, O, E, V, R, L, Ex, A, D>
```

where:

- `C` — Candidate identity.
- `K` — Claim or claim set.
- `X` — Qualification context.
- `P` — Qualification profile.
- `O` — Evidence obligations.
- `E` — Evidence records.
- `V` — Evidence validity and applicability determinations.
- `R` — Evaluator records.
- `L` — Limitations and uncertainty.
- `Ex` — Exceptions or waivers.
- `A` — Qualification authority.
- `D` — Qualification disposition.

## 2. Candidate

A **Candidate** is the exact artifact, state, configuration, model, dataset, document, protocol revision, build, package, or other bounded object about which a claim is being qualified.

A candidate MUST have stable identity sufficient to distinguish it from materially different candidates.

Candidate identity SHOULD include, where applicable:

- stable ID;
- version;
- content digest or immutable revision;
- baseline identity;
- composition manifest;
- creation timestamp;
- declared dirty/unknown state.

If a material property changes after evidence is collected, the resulting object MUST be treated as a new candidate or the affected evidence MUST be explicitly invalidated.

## 3. Claim

A **Claim** is the bounded proposition whose support is being qualified.

A claim MUST declare:

- stable claim ID;
- subject candidate;
- proposition;
- claim class;
- scope;
- exclusions;
- target context;
- required maturity;
- falsification condition or rejection rule where feasible.

A qualification MUST NOT silently generalize beyond the declared claim scope.

Examples:

- `candidate X conforms to schema Y`;
- `candidate X preserves backward compatibility with baseline B`;
- `candidate X satisfies the release profile for environment Z`;
- `candidate X produced lower median latency than baseline B under workload W`;
- `candidate X is empirically validated for population P under study S`.

These are distinct claims and may receive distinct dispositions.

## 4. Context

Qualification context defines the validity domain of the result.

Context MAY include:

- environment;
- platform;
- population;
- workload;
- jurisdiction;
- time window;
- dependency versions;
- network condition;
- device class;
- evaluator availability;
- data snapshot;
- protocol or policy revision.

A context omitted from evidence MUST NOT be inferred unless the qualification profile explicitly permits it.

## 5. Qualification profile

A **Qualification Profile** declares what evidence is required for a class of claim or promotion boundary.

A profile MUST declare:

- profile identity and version;
- applicable claim classes;
- required evidence obligations;
- evaluator constraints;
- allowed evidence states;
- required independence, if any;
- validity/freshness rules;
- exception rules;
- minimum disposition rules;
- protected promotion boundary, if the profile feeds one.

Profiles are domain adapters. They MAY define domain-specific test names, evidence types, risk classes, or radius systems without changing EQP core semantics.

## 6. Evidence obligation

An **Evidence Obligation** states what must be established before a claim can receive a requested qualification.

Each obligation MUST declare:

- obligation ID;
- claim(s) it supports;
- evidence class;
- required/conditional/optional status;
- applicable context;
- evaluator requirements;
- success criteria;
- failure criteria;
- inconclusive criteria;
- freshness or invalidation rules;
- required reproduction data.

Missing REQUIRED evidence MUST NOT be treated as passing evidence.

## 7. Evidence record

Each material evidence record MUST identify:

- evidence ID;
- candidate ID;
- claim or obligation IDs;
- source artifact/observation;
- method;
- environment/context;
- evaluator;
- provenance;
- timestamp;
- result;
- limitations;
- reproduction method or reason reproduction is impossible.

Allowed baseline result classes are:

```text
PASS
FAIL
PARTIAL
INCONCLUSIVE
BLOCKED
NOT_RUN
NOT_APPLICABLE
```

`BLOCKED`, `INCONCLUSIVE`, and `NOT_RUN` MUST remain distinct from `PASS`.

## 8. Evidence validity

Evidence validity is not equivalent to evidence existence.

Each evidence item MUST be assessed for:

- identity binding;
- claim relevance;
- context applicability;
- provenance completeness;
- evaluator validity;
- freshness;
- reproducibility where required;
- integrity/tamper status where required;
- supersession;
- dependency validity.

Evidence MAY be:

```text
VALID
INVALID
STALE
SUPERSEDED
OUT_OF_SCOPE
UNVERIFIABLE
```

Invalid or stale evidence MUST NOT satisfy a required obligation unless an explicit exception is permitted and recorded.

## 9. Evidence inheritance and invalidation

A new candidate MAY inherit valid evidence from a baseline when the qualification profile and semantic delta establish that the evidence's supported claim remains unaffected.

Evidence inheritance MUST record:

- baseline candidate;
- inherited evidence ID;
- supported claim;
- delta analysis;
- reason evidence remains valid;
- authority/evaluator that confirmed inheritance.

Evidence MUST be invalidated when the delta affects a dependency, assumption, input, environment, evaluator basis, or semantic surface on which the evidence depends.

The generalized required-evidence rule is:

```text
RequiredEvidence(candidate_n)
=
InvalidatedEvidence(candidate_{n-1} -> candidate_n)
+ EvidenceForNewClaims(candidate_n)
+ MandatoryProfileEvidence
```

This equation defines an obligation set, not a statistical proof of sufficiency.

## 10. Evaluation

An **Evaluation** applies a declared method to evidence or a candidate and produces an evidence record or evidence-validity determination.

Evaluation MUST remain distinct from qualification.

An evaluator MAY be:

- deterministic software;
- a test harness;
- a human specialist;
- an independent reviewer;
- a measurement apparatus;
- a model or agent where the profile permits;
- a multi-evaluator panel.

Evaluator identity, capability, and relevant conflicts MUST be recorded when material to the claim.

## 11. Qualification disposition

Core dispositions are:

```text
QUALIFIED
NOT_QUALIFIED
BLOCKED
SUPERSEDED
```

A profile MAY add sub-dispositions but MUST map them to one core disposition.

### QUALIFIED

All REQUIRED obligations are satisfied by valid applicable evidence; no unresolved blocking contradiction exists; required authority for qualification is present.

### NOT_QUALIFIED

One or more required obligations fail, or evidence positively contradicts the claim.

### BLOCKED

The protocol cannot determine qualification because required evidence, evaluator capability, context, provenance, authority, or dependency is unavailable or unresolved.

### SUPERSEDED

The qualification refers to a candidate or qualification record replaced by a later authoritative candidate or record.

## 12. Weakest-justified claim rule

A qualification MUST use the weakest claim or maturity justified by the available valid evidence.

For example:

```text
artifact exists -> documented/produced
runtime executed -> implemented/observed
repeatable checks pass -> tested/conforming
field study supports declared claim -> empirically supported/validated only within study scope
```

A passing implementation test MUST NOT be promoted to an empirical human-outcome claim.

## 13. Negative and inconclusive evidence

Negative, partial, bounded, contradictory, and inconclusive evidence MUST be retained when it materially bears on future qualification.

A subsequent positive result MUST NOT erase the historical negative result; it may supersede its applicability through an explicit record.

## 14. Exceptions

An **Exception** is an explicit authority decision to proceed despite an unmet or non-passing obligation.

An exception MUST record:

- exception ID;
- unmet obligation;
- evidence state;
- rationale;
- accepting authority;
- scope;
- expiration/review condition;
- downstream limitation.

An exception MUST NOT rewrite the evidence state to `PASS`.

EQP records exceptions but does not create promotion authority.

## 15. Qualification attestation

A **Qualification Attestation** is the durable record of one qualification determination.

It MUST bind:

- candidate;
- claim set;
- profile;
- obligation set;
- evidence set;
- evidence validity;
- evaluator set;
- limitations;
- exceptions;
- disposition;
- qualifying authority;
- timestamp;
- integrity identifier/digest when the environment supports one.

A qualification attestation SHOULD be append-only after issuance. A corrected determination SHOULD create a superseding attestation rather than silently editing historical state.

## 16. Promotion boundary

EQP MUST distinguish:

```text
Evidence -> Evaluation -> Qualification -> Promotion Decision -> Status/State
```

A `QUALIFIED` disposition means only that the candidate/claim satisfied the declared qualification profile.

It does not itself mean:

- deploy;
- publish;
- release;
- adopt;
- buy;
- approve spending;
- change canonical policy;
- authorize irreversible action.

Those are controlled by an external authority system.

## 17. Post-promotion qualification

A project MAY run EQP again after promotion against a new claim such as:

- deployed identity matches qualified identity;
- production health satisfies thresholds;
- field behavior matches pre-promotion evidence;
- interoperability holds in the target ecosystem;
- empirical outcomes satisfy study criteria.

Post-promotion qualification MUST remain a separate qualification record because its context and evidence differ.

## 18. Qualification radius

EQP core does not require a universal radius vocabulary, but profiles MAY declare a **Qualification Radius** to bound semantic reach.

Recommended generic levels:

```text
R1 LOCAL      — changed object only
R2 INTERFACE  — changed object + direct producers/consumers/contracts
R3 SYSTEM     — reachable shared state, dependencies, and critical paths
R4 ECOSYSTEM  — independently governed systems or cross-domain assumptions
```

Radius is a verification-scope claim, not a risk score and not a version number.

## 19. Versioning

EQP protocol, schemas, profiles, examples, and implementations SHOULD version independently.

Equal version numbers MUST NOT be treated as proof of conformance.

A conformance record SHOULD explicitly bind:

```text
EQP protocol version
schema version
profile version
implementation version
candidate identity
```

## 20. Non-goals

EQP does not define:

- universal truth;
- universal quality;
- a single evidence weighting formula;
- a universal risk score;
- a universal release policy;
- a universal scientific validity threshold;
- domain-specific test methods;
- promotion authority.

--- FILE: 02-FORMAL-MODEL.md (172 lines, 4.9 KiB) ---
# EQP Formal Model

## 1. Objects

Let:

- `C` be the set of candidates.
- `K` be the set of claims.
- `X` be the set of contexts.
- `P` be the set of qualification profiles.
- `O` be the set of evidence obligations.
- `E` be the set of evidence records.
- `R` be the set of evaluators.
- `A` be the set of qualification authorities.
- `D = {QUALIFIED, NOT_QUALIFIED, BLOCKED, SUPERSEDED}`.

A qualification request is:

```text
QR = (c, Kc, x, p)
```

where `c in C`, `Kc subset K`, `x in X`, `p in P`.

The profile expands the request into an obligation set:

```text
O_req = obligations(p, Kc, x)
```

Evidence is mapped to obligations through an applicability relation:

```text
supports(e, o, c, x) -> {true, false}
```

and a validity relation:

```text
valid(e, c, x) -> {VALID, INVALID, STALE, SUPERSEDED, OUT_OF_SCOPE, UNVERIFIABLE}
```

An obligation satisfaction function is:

```text
sat(o, E, c, x, p) -> {PASS, FAIL, PARTIAL, INCONCLUSIVE, BLOCKED, NOT_RUN, NOT_APPLICABLE}
```

## 2. Core qualification rule

For a profile with required obligations `O_R`:

```text
QUALIFIED iff
  forall o in O_R:
    sat(o, E, c, x, p) satisfies profile acceptance
  and no blocking contradiction exists
  and qualification authority is valid.
```

```text
NOT_QUALIFIED iff
  exists o in O_R such that sat(o, E, c, x, p) = FAIL
  or valid contradictory evidence defeats a required claim.
```

```text
BLOCKED iff
  neither QUALIFIED nor NOT_QUALIFIED can be established
  because required information, evidence, evaluator, context,
  provenance, dependency, or authority is unavailable.
```

`SUPERSEDED` is historical, not epistemic: it means the record no longer names the current candidate/qualification but remains part of lineage.

## 3. Monotonicity constraints

EQP does not assume evidence accumulation is globally monotonic. New evidence may defeat an earlier qualification.

However, the following record-level monotonicity rules apply:

1. Historical evidence records are retained.
2. A later record may invalidate or supersede an earlier record but must not erase it.
3. A later qualification may narrow, overturn, or supersede an earlier qualification with explicit lineage.
4. A candidate change cannot inherit evidence without an explicit applicability determination when the profile requires one.

## 4. Candidate-relative qualification

Qualification is not a unary predicate `Qualified(c)`.

The proper relation is:

```text
Qualified(c, k, x, p, E)
```

This prevents absolute statements such as “candidate X is qualified” from silently collapsing multiple claims and contexts.

## 5. Evidence inheritance

For baseline `c0` and candidate `c1`, evidence `e` may be inherited only if:

```text
same_relevant_subject(e, c0, c1)
and unaffected(delta(c0,c1), dependencies(e))
and context_compatible(e.context, c1.context)
and profile_allows_inheritance(e, p)
and validity(e) = VALID
```

If any predicate is unknown and the profile requires certainty, inheritance is BLOCKED.

## 6. Evidence radius

Let `G` be a dependency/reachability graph over claims, components, contracts, or semantic surfaces.

For delta `d`, a profile may define:

```text
Affected(d) = Reachable(seed(d), G, policy)
```

Evidence whose support set intersects `Affected(d)` is a candidate for invalidation.

EQP does not prescribe how `G` is built. A release profile might use source and contract dependencies; a research profile might use variable/measurement dependencies.

## 7. Contradiction

Two evidence items conflict when they support mutually incompatible propositions under overlapping contexts.

A profile MUST define whether contradiction:

- fails an obligation;
- requires adjudication;
- yields `INCONCLUSIVE`;
- triggers a higher-radius evaluation;
- triggers a human decision process.

No universal weighting scheme is defined by EQP.

## 8. Maturity lattice

EQP recommends a partially ordered maturity model rather than one scalar score.

At minimum:

```text
Documented
Implemented
Tested
Empirically Validated
```

These are not strictly interchangeable and may be tracked as dimensions rather than a single chain. Qualification MUST NOT infer a stronger dimension from a weaker one.

## 9. Soundness target

A conforming EQP implementation should satisfy **qualification soundness relative to its declared profile**:

> It does not emit `QUALIFIED` when a required obligation is unsatisfied, invalid, missing, or outside the allowed exception policy.

This is mechanically testable for finite fixtures.

EQP cannot in general prove that an evidence obligation itself is scientifically sufficient for truth. That is a domain/profile validity question.

## 10. Completeness target

A conforming implementation may aim for **procedural completeness**:

> Every declared obligation reaches a typed disposition and every evidence item is either consumed, rejected, retained as contradictory, or marked out of scope.

This is distinct from epistemic completeness; unknowns may remain.

--- FILE: 03-PROOF-AND-FALSIFICATION.md (147 lines, 6.8 KiB) ---
# EQP Proof and Falsification Framework

## 1. What “prove” means here

EQP deliberately separates four kinds of proof-like claim:

### 1. Structural proof

A machine-readable record conforms to a schema or formal invariant.

Example: an attestation contains candidate ID, profile ID, evidence lineage, disposition, and authority.

This can be mechanically proven over finite records.

### 2. Procedural proof

A conforming implementation followed declared EQP transition and decision rules.

Example: a REQUIRED obligation with `NOT_RUN` evidence cannot produce `QUALIFIED`.

This can be proven through conformance vectors, mutation tests, model checking for a bounded implementation, or reference tests.

### 3. Domain conformance proof

Evidence establishes that a candidate satisfies a declared domain contract.

Example: an SES candidate preserves semantic identity across required projection vectors.

EQP can prove that the correct domain evidence was required, bound, and evaluated. The domain protocol/evaluator establishes the domain property.

### 4. Empirical support

Observed data supports a real-world claim within a declared study scope.

This is not established by EQP conformance itself. It requires a suitable empirical design, prospective criteria where appropriate, and valid measurements.

## 2. Proof obligations for EQP core

The EQP reference implementation or any implementation claiming Core Conformance MUST demonstrate at least:

| ID | Invariant | Positive proof | Required negative test |
|---|---|---|---|
| P-01 | Candidate binding | evidence for candidate A qualifies A | evidence for A cannot qualify B |
| P-02 | Claim binding | evidence supports declared claim | evidence for unrelated claim is rejected/out-of-scope |
| P-03 | Context binding | applicable context accepted | incompatible context cannot satisfy obligation |
| P-04 | Required evidence honesty | all required PASS -> potentially QUALIFIED | required NOT_RUN/BLOCKED cannot become QUALIFIED |
| P-05 | Failure honesty | FAIL produces NOT_QUALIFIED where required | FAIL cannot be rewritten as PASS |
| P-06 | Inconclusive honesty | missing evaluator can yield BLOCKED/INCONCLUSIVE | missing evaluator cannot silently pass |
| P-07 | Provenance | complete provenance accepted | missing required provenance blocks satisfaction |
| P-08 | Reproduction | required reproduction method bound | absent required reproduction blocks qualification |
| P-09 | Weakest claim | tested evidence supports tested claim | tested evidence cannot establish empirical validation |
| P-10 | Negative retention | failed evidence persists in lineage | later PASS cannot delete prior FAIL record |
| P-11 | Supersession | new attestation points to old | old attestation is not silently mutated |
| P-12 | Exception honesty | exception records unmet obligation | exception cannot mutate obligation result to PASS |
| P-13 | Authority separation | qualification authority can attest | qualification alone cannot execute promotion |
| P-14 | Evidence invalidation | affected inherited evidence is invalidated | stale baseline evidence cannot silently carry forward |
| P-15 | Evidence inheritance | unaffected valid evidence may carry forward | inheritance without required applicability proof is blocked |
| P-16 | Contradiction visibility | contradictory evidence remains visible | contradiction cannot be discarded because preferred evidence passes |

## 3. Falsification criteria for protocol claims

EQP should make only claims that can be challenged.

### Claim A — “EQP prevents unsupported qualification under a declared profile.”

Falsified if a conforming fixture can cause `QUALIFIED` while a REQUIRED obligation is unsatisfied without an allowed exception.

### Claim B — “EQP preserves distinction between evidence and promotion authority.”

Falsified if a core EQP conformance path grants or executes promotion solely because qualification passed.

### Claim C — “EQP prevents maturity overclaim.”

Falsified if evidence classified only as implementation/test evidence can mechanically yield an empirical-validation qualification without an empirical obligation/evidence path.

### Claim D — “EQP preserves negative and inconclusive evidence.”

Falsified if a later positive qualification deletes, overwrites, or makes unrecoverable a material negative/inconclusive record.

### Claim E — “EQP qualification is candidate/claim/context specific.”

Falsified if one qualification can be reused for a materially different candidate, claim, or context without an explicit inheritance/applicability determination.

### Claim F — “EQP supports selective evidence invalidation.”

Falsified if a profile that declares dependencies cannot distinguish unaffected inherited evidence from evidence whose dependency changed.

## 4. Claims EQP v0.1.0 must NOT make yet

Until empirically studied, the protocol must not claim that EQP:

- reduces real-world defect rates;
- improves release quality;
- reduces human QA cost;
- improves scientific reproducibility;
- outperforms conventional QA or peer review;
- yields optimal evidence allocation;
- produces universally correct qualification decisions;
- eliminates evaluator bias;
- provides a universal measure of confidence.

These are research hypotheses.

## 5. Prospective validation program

To demonstrate value beyond internal coherence, pre-register comparative studies.

Suggested studies:

### Study 1 — Overclaim prevention

Compare teams using ordinary pass/fail release review versus EQP qualification records. Measure unsupported maturity/status claims detected by independent audit.

### Study 2 — Evidence reuse accuracy

Measure whether explicit evidence invalidation retains unaffected evidence without missing regressions compared with full retest and ad hoc selective retest.

### Study 3 — External QA handoff

Measure defect reproduction rate, evidence completeness, and triage time when external QA uses EQP evidence obligations versus conventional free-form test reports.

### Study 4 — Protocol/research qualification

Apply EQP to a non-software domain and measure whether independent reviewers reproduce the same qualification disposition from the same frozen packet.

Each study should define hypotheses, sampling, outcome metrics, exclusions, stopping rules, and publish-regardless conditions before execution.

## 6. Proof packet

A strong EQP qualification should be independently auditable from one frozen packet containing:

```text
candidate manifest
claim definitions
qualification profile
obligation expansion
all evidence records
all evidence validity decisions
evaluator identities/capabilities
limitations and contradictions
exceptions
qualification algorithm/version
attestation
reproduction instructions
```

An auditor should be able to recompute the procedural disposition without access to the original author's private reasoning.

--- FILE: 04-CONFORMANCE.md (91 lines, 2.7 KiB) ---
# EQP Conformance

## 1. Principle

EQP conformance proves declared protocol behavior. It does not prove that the adopted qualification profile is scientifically sufficient, that the candidate is useful, or that promotion is wise.

## 2. Conformance levels

### Level 1 — Record Conformance

Implementation can validate:

- Candidate
- Claim
- QualificationProfile
- EvidenceObligation
- EvidenceRecord
- QualificationAttestation

### Level 2 — Qualification Engine

Additionally implements:

- obligation expansion;
- evidence-to-obligation binding;
- evidence validity states;
- core dispositions;
- weakest-justified-claim rule;
- exception honesty.

### Level 3 — Lineage and Invalidation

Additionally implements:

- baseline/candidate lineage;
- evidence inheritance;
- evidence invalidation;
- superseding attestations;
- negative/inconclusive retention.

### Level 4 — Auditable Qualification

Additionally provides:

- deterministic or reproducible disposition computation where possible;
- complete proof packet export;
- independent replay;
- mutation test suite for P-01 through P-16;
- explicit evaluator and authority identity.

### Level 5 — Domain Profile Conformance

Additionally demonstrates one or more registered profiles with domain-specific evidence semantics, such as release, research, protocol, dataset, model, or SES conformance.

### Level 6 — Empirically Evaluated EQP Use

Requires prospective empirical study of EQP itself. This level cannot be achieved by protocol/schema conformance alone.

## 3. Mandatory negative vectors

A Core Level 2 implementation MUST reject or block at least these cases:

1. required evidence is `NOT_RUN`;
2. required evidence is bound to a different candidate;
3. required evidence has missing mandatory provenance;
4. required evidence is stale under profile rules;
5. evidence supports a different claim;
6. empirical-validation claim has only unit/integration evidence;
7. exception exists but no accepting authority;
8. promotion action is attempted by the core qualification engine;
9. attestation is silently edited after issuance;
10. inherited evidence depends on a changed dependency and has not been requalified.

## 4. Reference output

For a fixed qualification packet, conforming implementations SHOULD emit a normalized decision summary:

```json
{
  "candidateId": "candidate.example.1",
  "claimIds": ["claim.example.conformance"],
  "profileId": "eqp:profile/core-example@0.1.0",
  "disposition": "QUALIFIED",
  "satisfiedRequired": 3,
  "failedRequired": 0,
  "blockedRequired": 0,
  "exceptions": 0
}
```

Byte-identical serialization is optional unless an implementation profile requires it; semantic equality is required.

--- FILE: 05-PROTOCOL-RELATIONSHIPS.md (70 lines, 3.0 KiB) ---
# EQP Protocol Relationships

## 1. FCI

**FCI contributes:** epistemic distinctions among representation, observation, evidence, interpretation, conformance, and empirical validity.

**EQP uses:** the principle that a record or executable conformance result does not automatically justify broader empirical or interpretive claims.

**Boundary:** EQP does not redefine FCI concepts or claim FCI empirical validity.

## 2. ICP

**ICP contributes:** declared interaction boundaries, participants, authority, evidence, verification, invariants, outcomes, recovery, receipts, uncertainty, and the separation:

```text
Evidence -> Evaluation -> Decision -> Status
```

**EQP uses:** evidence and verification outputs from an ICP interaction as qualification inputs.

**Boundary:** ICP defines what a bounded interaction requires; EQP determines what collected evidence justifies claiming about a candidate/interaction implementation.

## 3. IEPE

**IEPE contributes:** governed execution from intent through issues, artifacts, evaluation, evidence, qualification, and promotion; candidate/evaluator/provenance binding; negative-result retention; protected promotion authority.

**EQP extracts/generalizes:** the qualification segment so it can operate independently of any specific project execution engine.

**Boundary:**

```text
IEPE: intent -> work -> artifact -> evaluation -> evidence -> qualification -> promotion
EQP:                                            [ qualification ]
```

IEPE may call or adopt EQP for qualification. EQP does not replace IEPE work graphs, claims, dispatch, coordination, or promotion governance.

## 4. PDP

**PDP contributes:** governance for consequential decisions under uncertainty, with human custody over weights, stakes, and exit; preregistration; frozen commitments; outcome-blind audit.

**EQP uses:** PDP when qualification leaves a consequential decision among conflicting, incomplete, or exception-bearing evidence that cannot be mechanically resolved.

**Boundary:** EQP reports what evidence justifies. PDP may govern what an authorized human decides to do about it.

## 5. SES

**SES contributes:** domain-specific conformance obligations concerning semantic identity, projection, operations, accessibility, deterministic resolution, and expression invariants.

**EQP uses:** SES evaluator results as evidence for SES-specific claims.

**Boundary:** SES defines what conformance means; EQP defines whether the required conformance evidence is present, valid, current, and sufficient under a profile.

## 6. General domain protocols

The rule is:

> Domain protocols define evidence semantics. EQP defines qualification semantics.

A domain profile may register:

- claim classes;
- obligations;
- evaluators;
- evidence types;
- context dimensions;
- invalidation dependencies;
- authority requirements.

It may not weaken EQP core honesty invariants such as missing-evidence distinction, candidate binding, negative-result retention, or qualification/promotion separation.

--- FILE: 06-PROFILES.md (54 lines, 2.8 KiB) ---
# EQP Reference Profiles

Profiles specialize EQP without changing its core semantics.

## 1. Release Qualification Profile

Candidate: immutable build/package/revision.  
Claims: compatibility, deployability, product behavior, migration safety.  
Typical evidence: automated gates, functional QA, regression, exploratory testing, device/browser matrix, migration/rollback, performance, security.  
Typical radius: R1-R4.  
Promotion authority: release owner or equivalent.

## 2. Protocol Conformance Profile

Candidate: protocol implementation or specification revision.  
Claims: schema conformance, lifecycle behavior, invariant preservation, migration compatibility.  
Evidence: conformance vectors, reference implementation comparison, negative fixtures, cross-language parity.  
Promotion authority: protocol governance body/owner.

## 3. Research Claim Profile

Candidate: study result, model, hypothesis result, or research package.  
Claims: bounded empirical findings.  
Evidence: preregistration, raw observations, analysis method, uncertainty, negative results, independent reproduction where feasible.  
Exceptions: cannot waive missing empirical data into existence.  
Promotion authority: publication/research authority external to EQP.

## 4. Dataset Qualification Profile

Candidate: immutable dataset snapshot + manifest.  
Claims: schema validity, provenance completeness, coverage, label quality, contamination bounds, reproducibility.  
Evidence: source lineage, sampling audit, disagreement review, checksums, schema checks, holdout evaluation.  
Invalidation: source changes, transformation changes, label-policy changes, dedupe changes.

## 5. Model Qualification Profile

Candidate: exact weights + tokenizer/runtime/configuration + lineage.  
Claims: benchmark performance, robustness, safety properties, serving compatibility.  
Evidence: frozen evaluation sets, perturbation tests, independent evaluator runs, latency/cost measurements, deployment smoke.  
Qualification MUST identify whether claims apply to model weights, serving stack, or combined system.

## 6. Document / Policy Qualification Profile

Candidate: immutable revision/digest.  
Claims: completeness, consistency, authority alignment, review completion, legal/policy conformance.  
Evidence: authority trace, contradiction scan, required reviewer attestations, referenced-source integrity.  
Promotion: publication/adoption remains external.

## 7. Physical / Operational Profile

Candidate: prototype/configuration/process revision.  
Claims: functional, safety, tolerance, operating-environment behavior.  
Evidence: inspection, calibration, destructive/non-destructive tests, field trials, operator observations.  
Context must name physical/environmental conditions; lab evidence cannot silently generalize to field claims.

--- FILE: 07-ADOPTION.md (52 lines, 1.8 KiB) ---
# EQP Adoption Guide

## 1. Adoption principle

Adopt EQP as a qualification layer, not as a second project-management lifecycle.

Existing issue trackers, CI systems, research workflows, approval boards, or release systems may remain authoritative for their own state.

## 2. Minimum adoption inputs

```yaml
project_id: ""
eqp_protocol: "eqp:protocol/evidence-qualification@0.1.0"
eqp_revision: "<immutable digest/tag>"
authority_order: []
qualification_profiles: []
evidence_stores: []
evaluators: []
qualification_authorities: []
promotion_authorities: []
protected_actions: []
```

## 3. First adoption cycle

1. Identify existing candidate identities.
2. Inventory current claims made by project status/release/research records.
3. Inventory current evidence and evidence stores.
4. Identify evaluators and their capability/independence.
5. Identify promotion authorities separately from evaluators.
6. Map one existing promotion boundary into an EQP profile.
7. Freeze one candidate and replay qualification retrospectively.
8. Record mismatches without rewriting history.
9. Run one prospective qualification before expanding scope.

## 4. Do not duplicate authority

EQP records should link to canonical project/domain sources instead of restating architecture, policy, or domain contracts.

## 5. Adoption success criteria

An adoption is minimally useful when an independent reviewer can answer:

- What exact candidate is being judged?
- What exact claims are being made?
- Which profile generated the evidence obligations?
- Which obligations are satisfied, failed, blocked, or excepted?
- What evidence supports each determination?
- What limitations remain?
- Who qualified the evidence?
- Who, separately, may authorize promotion?
- Can the qualification be reproduced from the packet?

--- FILE: 08-REFERENCE.md (84 lines, 1.4 KiB) ---
# EQP Reference

## One sentence

EQP determines what a declared body of evidence justifies claiming about an exact candidate in a declared context.

## Do not collapse

```text
Candidate != Claim != Evidence != Evaluation != Qualification != Promotion
```

## Qualification request

```text
candidate + claim(s) + context + profile
```

## Profile expands to

```text
required evidence obligations + evaluator constraints + validity rules + exception policy
```

## Evidence record

```text
candidate
claim/obligation
source
method
context
evaluator
provenance
timestamp
result
limitations
reproduction
```

## Results

```text
PASS
FAIL
PARTIAL
INCONCLUSIVE
BLOCKED
NOT_RUN
NOT_APPLICABLE
```

## Evidence validity

```text
VALID
INVALID
STALE
SUPERSEDED
OUT_OF_SCOPE
UNVERIFIABLE
```

## Qualification

```text
QUALIFIED
NOT_QUALIFIED
BLOCKED
SUPERSEDED
```

## Golden rules

1. Missing evidence is not passing evidence.
2. Evidence for A does not qualify B.
3. Evidence in context X does not silently generalize to Y.
4. A test result does not become an empirical claim by wording.
5. Negative and inconclusive evidence remains in lineage.
6. Exceptions preserve the failure/missing state; they do not rewrite it.
7. Qualification does not grant promotion authority.
8. Candidate changes invalidate evidence selectively, not magically all-or-none.
9. A candidate may be qualified for one claim and unqualified for another.
10. Use the weakest claim justified by valid evidence.

--- FILE: README.md (78 lines, 5.7 KiB) ---
# Evidence Qualification Protocol

EQP is a project-independent specification for deciding what a body of evidence actually justifies. Given one candidate, one claim, one context and a declared set of evidence, it produces a qualification: qualified, not qualified, blocked or superseded. It never authorizes release or deployment on its own.

**Identifier:** `eqp:protocol/evidence-qualification` · **Version:** 0.1.0 · **Status:** Normative candidate

## What it does

EQP separates six things that are often run together: the candidate being judged, the claim made about it, the evidence gathered, the evaluation of that evidence, the resulting qualification, and the promotion decision that may follow. Its core invariant is `Candidate != Claim != Evidence != Evaluation != Qualification != Promotion`. A candidate can be qualified for one claim and not another, and a qualification is an input to promotion authority, never a grant of it.

## Features

- Explicit objects for candidates, claims, contexts, qualification profiles, evidence obligations and evidence records, each with its own identity.
- Rules for evidence validity: provenance, applicability, freshness, and evaluator identity and independence.
- Evidence inheritance across versions, with invalidation whenever a change touches something the evidence depends on.
- Four core dispositions (`QUALIFIED`, `NOT_QUALIFIED`, `BLOCKED`, `SUPERSEDED`) that profiles may refine but must map back to.
- A weakest-justified-claim rule: a passing implementation test cannot be promoted to an empirical claim about people.
- Retention of negative and inconclusive results, recorded exceptions, and qualification attestations that bind the result to its inputs.
- Six conformance levels, mandatory negative test vectors, and reference profiles for releases, protocols, research claims, datasets, models, documents and physical operations.
- JSON Schemas for candidates, evidence records, qualification profiles and attestations, with positive and negative examples.

## How it works

The canonical flow runs from a baseline and a candidate, through a semantic delta and a claim set, to a qualification profile that sets evidence obligations. Evidence is collected and evaluated, checked for validity and invalidation, and turned into a qualification and an attestation. Promotion is a separate, external decision that consumes that attestation.

The obligation set for a new version is defined as:

```text
RequiredEvidence(candidate_n)
  = InvalidatedEvidence(candidate_{n-1} -> candidate_n)
  + EvidenceForNewClaims(candidate_n)
  + MandatoryProfileEvidence
```

The specification states that this defines what must be gathered, not a statistical proof that it is enough.

EQP is the qualification segment of the Intent and Evidence Project Engine (IEPE), extracted so it can run without that engine. It consumes the evidence and verification outputs of the Interaction Contract Protocol (ICP). `05-PROTOCOL-RELATIONSHIPS.md` states each boundary.

## What this explores

- Treating "is this claim justified?" as a question with a formal answer that is separate from "should we ship?".
- Making evidence reuse across versions safe by requiring a recorded delta analysis instead of assuming old results still hold.
- Encoding over-claiming as a testable failure, through negative vectors such as a request for an empirical claim backed only by automated tests.
- Keeping negative results as permanent project memory.

## Contents

| File | What it holds |
| :--- | :--- |
| [`00-README.md`](00-README.md) | Package overview, core question, canonical flow |
| [`01-EQP-SPECIFICATION.md`](01-EQP-SPECIFICATION.md) | The normative protocol (sections 0–20) |
| [`02-FORMAL-MODEL.md`](02-FORMAL-MODEL.md) | Formal objects, relations, invariants and decision semantics |
| [`03-PROOF-AND-FALSIFICATION.md`](03-PROOF-AND-FALSIFICATION.md) | What can be proved, how, and what would falsify each claim |
| [`04-CONFORMANCE.md`](04-CONFORMANCE.md) | Conformance levels 1–6 and mandatory negative vectors |
| [`05-PROTOCOL-RELATIONSHIPS.md`](05-PROTOCOL-RELATIONSHIPS.md) | Boundaries with FCI, ICP, IEPE, PDP, SES and domain protocols |
| [`06-PROFILES.md`](06-PROFILES.md) | Reference qualification profiles |
| [`07-ADOPTION.md`](07-ADOPTION.md) | Adopting EQP in a project and mapping authority |
| [`08-REFERENCE.md`](08-REFERENCE.md) | Compact operator reference |
| [`schemas/`](schemas/) | Four JSON Schemas, also exported through `package.json` |
| [`examples/`](examples/) | One positive and two negative qualification examples |
| [`conformance/PROOF_MATRIX.md`](conformance/PROOF_MATRIX.md) | Claim-to-test matrix |
| [`.agents/`](.agents/) | Agent operating contract and generated full-text bundles |
| [`scripts/gen-llms.py`](scripts/gen-llms.py) | Regenerates the `.agents/` bundles |

## How to read this

1. Read [`00-README.md`](00-README.md) for the core question, the invariant and the flow.
2. Read [`01-EQP-SPECIFICATION.md`](01-EQP-SPECIFICATION.md) sections 1–3 (definition, candidate, claim), then 11–16 (dispositions through the promotion boundary).
3. Look at [`examples/negative-overclaim.json`](examples/negative-overclaim.json) to see the weakest-justified-claim rule applied.
4. Go to [`02-FORMAL-MODEL.md`](02-FORMAL-MODEL.md) and [`03-PROOF-AND-FALSIFICATION.md`](03-PROOF-AND-FALSIFICATION.md) for the formal treatment, and [`04-CONFORMANCE.md`](04-CONFORMANCE.md) if you are implementing it.

Status: EQP is a documented normative candidate. No implementation is declared, and it has not been reviewed outside the author. A conforming implementation would prove only the declared protocol behavior, not that any domain claim is true.

## License

MIT © Zach Shallbetter

Built by [Zach Shallbetter](https://zachshallbetter.com).

========================================================================
## SUBSYSTEM: MACHINE SCHEMAS & DEFINITIONS (4 files)
========================================================================

--- FILE: schemas/candidate.schema.json (22 lines, 0.7 KiB) ---
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://eqp.dev/schema/0.1/candidate.schema.json",
  "title": "EQP Candidate",
  "type": "object",
  "additionalProperties": false,
  "required": ["id", "kind", "identity"],
  "properties": {
    "id": {"type": "string", "minLength": 1},
    "kind": {"type": "string", "minLength": 1},
    "version": {"type": "string"},
    "identity": {
      "type": "object",
      "minProperties": 1,
      "additionalProperties": {"type": ["string", "number", "boolean"]}
    },
    "baselineId": {"type": ["string", "null"]},
    "createdAt": {"type": "string"},
    "dirty": {"type": ["boolean", "string"]},
    "manifestRefs": {"type": "array", "items": {"type": "string"}}
  }
}

--- FILE: schemas/evidence-record.schema.json (24 lines, 1.4 KiB) ---
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://eqp.dev/schema/0.1/evidence-record.schema.json",
  "title": "EQP Evidence Record",
  "type": "object",
  "additionalProperties": false,
  "required": ["id", "candidateId", "obligationIds", "source", "method", "context", "evaluator", "provenance", "recordedAt", "result", "limitations"],
  "properties": {
    "id": {"type": "string", "minLength": 1},
    "candidateId": {"type": "string", "minLength": 1},
    "claimIds": {"type": "array", "items": {"type": "string"}},
    "obligationIds": {"type": "array", "minItems": 1, "items": {"type": "string"}},
    "source": {"type": ["string", "array"], "items": {"type": "string"}},
    "method": {"type": ["string", "array"], "items": {"type": "string"}},
    "context": {"type": "object"},
    "evaluator": {"type": "object", "required": ["id"], "properties": {"id": {"type": "string"}, "kind": {"type": "string"}, "independence": {"type": "string"}}, "additionalProperties": true},
    "provenance": {"type": ["string", "array"], "items": {"type": "string"}},
    "recordedAt": {"type": "string"},
    "result": {"enum": ["PASS", "FAIL", "PARTIAL", "INCONCLUSIVE", "BLOCKED", "NOT_RUN", "NOT_APPLICABLE"]},
    "validity": {"enum": ["VALID", "INVALID", "STALE", "SUPERSEDED", "OUT_OF_SCOPE", "UNVERIFIABLE"]},
    "limitations": {"type": "array", "items": {"type": "string"}},
    "reproduction": {"type": ["string", "null"]}
  }
}

--- FILE: schemas/qualification-attestation.schema.json (24 lines, 1.3 KiB) ---
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://eqp.dev/schema/0.1/qualification-attestation.schema.json",
  "title": "EQP Qualification Attestation",
  "type": "object",
  "additionalProperties": false,
  "required": ["id", "candidateId", "claimIds", "profile", "obligations", "evidenceRefs", "disposition", "qualificationAuthority", "recordedAt"],
  "properties": {
    "id": {"type": "string"},
    "candidateId": {"type": "string"},
    "claimIds": {"type": "array", "minItems": 1, "items": {"type": "string"}},
    "profile": {"type": "object", "required": ["id", "version"], "properties": {"id": {"type": "string"}, "version": {"type": "string"}}, "additionalProperties": false},
    "obligations": {"type": "array", "items": {"type": "object"}},
    "evidenceRefs": {"type": "array", "items": {"type": "string"}},
    "limitations": {"type": "array", "items": {"type": "string"}},
    "exceptions": {"type": "array", "items": {"type": "object"}},
    "disposition": {"enum": ["QUALIFIED", "NOT_QUALIFIED", "BLOCKED", "SUPERSEDED"]},
    "qualificationAuthority": {"type": "string"},
    "promotionAuthority": {"type": ["string", "null"]},
    "recordedAt": {"type": "string"},
    "supersedes": {"type": ["string", "null"]},
    "digest": {"type": ["string", "null"]}
  }
}

--- FILE: schemas/qualification-profile.schema.json (33 lines, 1.1 KiB) ---
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://eqp.dev/schema/0.1/qualification-profile.schema.json",
  "title": "EQP Qualification Profile",
  "type": "object",
  "additionalProperties": false,
  "required": ["id", "version", "claimClasses", "obligations", "dispositionPolicy"],
  "properties": {
    "id": {"type": "string"},
    "version": {"type": "string"},
    "claimClasses": {"type": "array", "minItems": 1, "items": {"type": "string"}},
    "obligations": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "requirement", "evidenceClass"],
        "properties": {
          "id": {"type": "string"},
          "requirement": {"enum": ["REQUIRED", "CONDITIONAL", "OPTIONAL"]},
          "evidenceClass": {"type": "string"},
          "successCriteria": {},
          "failureCriteria": {},
          "freshness": {},
          "evaluatorRequirements": {"type": "object"}
        },
        "additionalProperties": true
      }
    },
    "exceptionPolicy": {"type": "object"},
    "dispositionPolicy": {"type": "object"},
    "promotionBoundary": {"type": ["string", "null"]}
  }
}

========================================================================
## SUBSYSTEM: EXAMPLES & TEST VECTORS (4 files)
========================================================================

--- FILE: conformance/PROOF_MATRIX.md (26 lines, 1.8 KiB) ---
# EQP Proof Matrix

This matrix is the minimum proof plan for an implementation claiming EQP Core Conformance.

| Proof | Fixture | Expected | Mutation that must fail |
|---|---|---|---|
| P-01 Candidate binding | evidence A + candidate A | accepted | swap candidate to B |
| P-02 Claim binding | claim-specific evidence | accepted | bind unrelated claim |
| P-03 Context binding | same environment | accepted | incompatible environment |
| P-04 Required evidence | all required PASS | eligible | set one to NOT_RUN |
| P-05 Failure honesty | required FAIL | NOT_QUALIFIED | rewrite to QUALIFIED |
| P-06 Inconclusive honesty | evaluator unavailable | BLOCKED | treat unavailable as PASS |
| P-07 Provenance | complete provenance | accepted | delete source/provenance |
| P-08 Reproduction | required reproduction present | accepted | remove reproduction |
| P-09 Weakest claim | tests -> Tested | accepted | tests -> Empirically Validated |
| P-10 Negative retention | FAIL then PASS | both retained | delete FAIL |
| P-11 Supersession | attestation B supersedes A | lineage preserved | mutate A in place |
| P-12 Exception honesty | unmet + authorized exception | exception visible | rewrite unmet as PASS |
| P-13 Authority separation | QUALIFIED attestation | no promotion action | auto-deploy/auto-publish |
| P-14 Invalidation | changed dependency | stale/invalidated | inherit silently |
| P-15 Inheritance | unaffected dependency | inheritance allowed | inherit with unknown dependency state |
| P-16 Contradiction visibility | PASS + contrary evidence | contradiction visible | discard contrary evidence |

## Protocol claim status

The matrix can demonstrate procedural conformance of an implementation. It cannot demonstrate that EQP improves real-world outcomes. That requires the prospective empirical program in `03-PROOF-AND-FALSIFICATION.md`.

--- FILE: examples/negative-overclaim.json (10 lines, 0.5 KiB) ---
{
  "candidateId": "candidate.example.1",
  "requestedClaim": "Empirically Validated for human usability",
  "availableEvidence": [
    {"id": "ev.unit", "class": "automated-test", "result": "PASS"},
    {"id": "ev.integration", "class": "integration-test", "result": "PASS"}
  ],
  "expectedDisposition": "BLOCKED",
  "reason": "No human empirical evidence obligation is satisfied. Passing automated tests cannot establish an empirical human-outcome claim."
}

--- FILE: examples/negative-stale-inheritance.json (15 lines, 0.3 KiB) ---
{
  "baseline": "candidate.a",
  "candidate": "candidate.b",
  "delta": ["auth-session-contract"],
  "inheritedEvidence": {
    "id": "ev.session-regression.a",
    "dependencies": ["auth-session-contract"],
    "baselineResult": "PASS"
  },
  "expected": {
    "validity": "STALE",
    "satisfiesObligation": false,
    "qualification": "BLOCKED"
  }
}

--- FILE: examples/positive-qualification.json (18 lines, 0.5 KiB) ---
{
  "candidate": {
    "id": "candidate.example.1",
    "kind": "software-build",
    "version": "1.4.0-rc.1",
    "identity": {"commit": "abc123", "build": "build-481"},
    "baselineId": "candidate.example.0"
  },
  "claim": {
    "id": "claim.example.contract-conformance",
    "proposition": "candidate.example.1 conforms to contract example@1.0.0",
    "maturity": "Tested"
  },
  "profile": "eqp:profile/example-release@0.1.0",
  "evidence": ["ev.schema", "ev.integration", "ev.negative"],
  "disposition": "QUALIFIED",
  "promotion": "NOT_DECIDED"
}

========================================================================
## SUBSYSTEM: OTHER MODULES (1 files)
========================================================================

--- FILE: package.json (15 lines, 0.8 KiB) ---
{
  "name": "evidence-qualification-protocol",
  "version": "0.1.0",
  "description": "Evidence Qualification Protocol (EQP): qualification semantics for candidates, claims, evidence, and promotion. This package exposes the four normative JSON Schemas; the specification lives in the numbered documents.",
  "license": "UNLICENSED",
  "private": true,
  "files": ["schemas/", "01-EQP-SPECIFICATION.md", "00-README.md"],
  "exports": {
    "./candidate.schema.json": "./schemas/candidate.schema.json",
    "./evidence-record.schema.json": "./schemas/evidence-record.schema.json",
    "./qualification-profile.schema.json": "./schemas/qualification-profile.schema.json",
    "./qualification-attestation.schema.json": "./schemas/qualification-attestation.schema.json"
  },
  "keywords": ["evidence", "qualification", "attestation", "promotion", "specification"]
}