CEF Constitution: Binding Rules & Evidence Protocol

---

1. Intent & Truth Map Principle

The primary goal of the Codebase Evaluation Framework is to produce a truth map: an objective, portable, and reproducible assessment of codebase quality across the multidimensional diamond axes (detailed in DIAMOND_SCALE.md).

Evaluations must remain strictly decoupled from host-specific timelines, product launches, or individual programming language preferences. Context-specific lenses, compliance overlays, and language-specific tooling must be introduced exclusively through adapter packs applied after the baseline truth map is established.

---

2. Hard Invariants & Analysis Rules

All evaluation passes are bound by the following constitutional rules:

1. Zero Modifications During Analysis — Do not edit production code to prove a finding. Proof is reproducible evidence, not an ad-hoc patch.
2. Zero Silent Invention — Every recommendation and finding must cite at least one authoritative standard from the citation taxonomy (§5) and attach concrete evidence (§4).
3. Density-Aware Thoroughness — Adhere strictly to the budget density classifications (§6): exhaustive for discrete mechanical criteria; ranked Top-N for architectural and philosophical assessments.
4. Mandatory Adversarial Pairing — No specialist finding enters the final handoff package without an independent adversarial review and a documented resolution status (§7).
5. Architectural Legibility — Major subsystems, non-obvious algorithms, and state machines require referentially anchored diagrams conforming to DIAGRAM_CONTRACT.md.
6. Tooling Signal Over Speculation — Leverage available analyzers, linters, AST scanners, and targeted tests when they raise signal. Missing tools must be recorded as tooling gaps rather than excuses for incomplete analysis.
7. Targeted Test Execution — Full test suite runs are discouraged during evaluation. Prefer reading test suites as executable documentation. When executing a test is required to understand system behavior, record package, test name, timeout, and rationale.
8. Portable Domain Vocabulary — Findings must remain intelligible without host-specific jargon. Host-specific identifiers are permitted exclusively in local_refs[].

---

3. Operational Roles & Responsibilities

The evaluation lifecycle separates concerns across four distinct operational roles:

---

4. Evidence Grades & Handoff Criteria

Every finding must record an evidence_grade and contain one or more evidence[] items with kind matching: path_line, command_output, metric, ast_match, test_result, or external_citation.

---

5. Citation Taxonomy & Precedence Hierarchy

Every citation in a finding must declare its authoritative class:

---

6. Budget Density & Exhaustiveness Rules

To prevent analysis fatigue and balance thoroughness with execution cost, each lens operates under an assigned density class:

The default budget is N=10 unless overridden in the wave execution plan. Evaluators must explicitly declare their active N parameter in the report preamble.

---

7. Adversarial Audit Protocol & Resolution Enums

Adversarial auditors systematically challenge each specialist finding against six validation criteria:

1. False Positive Detection — Does the reported finding represent intended behavior, a standard idiom, or valid design?
2. Severity Calibration — Is the assigned severity proportional to actual blast radius and failure probability?
3. Root Cause Accuracy — Does the finding diagnose the fundamental defect rather than a superficial symptom?
4. Premature Abstraction — Does the proposed recommendation introduce unnecessary complexity, indirection, or gold-plating?
5. Lens Boundary Clarity — Is the finding better categorized and governed under a different evaluation lens?
6. Evidence Calibration — Is the declared evidence grade supported by reproducible artifacts?

Audit Resolutions

Every audited finding must be assigned one of the four mandatory resolution statuses:

---

8. Run Scope Declaration Contract

Prior to Wave 0 preflight, the operator or orchestrator must freeze the evaluation scope in run_scope.yaml:

cef_version: "0.1.0"
mode: "truth_map"
repo_root: "."
include_globs:
  - "**/*"
exclude_globs:
  - ".git/**"
  - "vendor/**"
  - "node_modules/**"
  - "**/*.pb.go"
languages_detected: []   # Populated during Wave 0 preflight
adapters_enabled: []     # e.g., ["go"]
top_n_default: 10
notes: ""

---

9. Mandatory Run Output Artifacts

Every completed CEF evaluation run must generate the following standard package artifacts:

---

10. Intellectual Honesty & Assessment Clauses

All participants in the evaluation process must adhere to the following principles of intellectual honesty:

• Acknowledge Assessment Boundaries — Explicitly record "unknown or unassessed" rather than projecting fabricated certainty.
• Recognize Pattern Conflicts — Report explicit design conflicts (Pattern A versus Pattern B) rather than forcing synthetic architectural purity.
• Differentiate Completeness from Style — Classify unfinished or partial implementations under completeness (CMP) rather than aesthetic criticism.
• Objective Depersonalization — Maintain detached, objective technical rigor. Critique repository artifacts, architecture, and evidence without personal commentary.