research-document
Framework Engineering
Framework Engineering
Purpose
Framework Engineering defines the methodology used to create, validate, evolve, and publish analytical frameworks.
It exists to ensure that frameworks evolve through evidence rather than intuition.
Framework Engineering currently governs:
- Echelon Diagnostic Framework (EDF)
- Clarity
Future frameworks should also follow this lifecycle.
Documentation
- Constitution
- Research Charter
- Foundation
- Research
- Applications
- Current State
- FEMS-1
- Identity-Capability Model
- Reference Corpus
- Reference Corpus Statistics
- Batch Findings Template
- Capability Vocabulary
- Lifecycle Values
- Constitutional Reviews
- Evidence Ledger
- Deferred Insights
- Artifact Maturity
- Knowledge Artifact Taxonomy
- Artifact Taxonomy
- Framework Definition
- Comparison Matrix
- KACS
- Operational Definitions
- Artifact Decision Tree
- Blind Review Protocol
- Multidimensional Classification
- Framework Engineering Cube
- Evaluation Principles
- Framework Canonical Model Standard
- Framework Validation Standard
- Release Readiness
- Adversarial Reference Cases
Core Principles
Reality First
Frameworks exist to better model reality.
When reality conflicts with the framework, the framework must change.
Evidence Before Evolution
Framework changes are driven by evidence.
Not inspiration.
Not elegance.
Not founder preference.
Reference Suite
Every framework maintains a Reference Suite.
Reference Cases are rerun whenever significant framework changes are proposed.
Reference Cases function as regression tests for the framework.
Validation modes:
- Reference Cases: test whether a framework works across domains.
- Longitudinal Reference Cases: test whether a framework evolves responsibly as evidence changes.
- Adversarial Reference Cases: test where a framework fails, overreaches, or fails safely.
- Constitutional Reviews: test whether the methodology complies with its own governing principles.
Frozen Versions
Published versions are immutable.
A framework version is frozen during evaluation.
Changes are introduced only in subsequent versions.
Engineering Change Requests (ECRs)
Every proposed framework modification is submitted as an Engineering Change Request.
Each ECR documents:
- Problem observed
- Evidence
- Proposed change
- Expected improvement
- Complexity cost
- Regression risk
- Validation plan
Concept Burden
Every concept carries the burden of proving its value.
To remain in a framework, a concept must:
- Improve understanding
- Improve one or more Reference Cases
- Preserve simplicity
- Resist simpler alternatives
No Sacred Concepts
No concept is immune from removal.
The framework serves reality.
Reality does not serve the framework.
Appropriate Precision
Framework Engineering avoids false precision.
Numbers are used when they represent meaningful measurements.
For qualitative judgments, Framework Engineering prefers evidence profiles, categorical assessments, and explicit rationale over single aggregate scores.
Canonical Model Standard
Framework Engineering requires frameworks to separate grammar, canonical information model, serializations, generated representations, and tools.
Framework Validation Standard
The Framework Validation Standard defines the release-readiness pipeline for frameworks governed by Framework Engineering.
It evaluates:
- concept support
- architecture stability
- adversarial robustness
- comparative differentiation
- independent reproducibility
- usability
- constitutional compliance
Foundation, Research, and Applications
Framework Engineering separates what is currently accepted from what is actively being tested.
- Foundation: conservative accepted knowledge and governing principles.
- Research: hypotheses, experiments, evidence, corpora, failed hypotheses.
- Applications: frameworks and tools that consume or test Framework Engineering.
Research Lifecycle
Reference Case
↓
Historical Baseline
↓
Independent Analyses
↓
Diagnostic Calibration
↓
Synthesis
↓
Framework Evaluation
↓
Engineering Change Requests
↓
Accept / Reject
↓
Publish Next Version
Cross-Framework Learning
Each Reference Case produces three reviews.
EDF Review
What did we learn about diagnosis?
Clarity Review
What did we learn about decision making?
Framework Engineering Review
What did we learn about building analytical frameworks?
Version 1.0 Publication Criteria
A framework may be published as Version 1.0 only after:
- Successfully completing the Reference Suite.
- Demonstrating value across multiple domains.
- Producing measurable improvements over baseline methods.
- Remaining practical for everyday use.
- Satisfying constitutional requirements.
- Completing Diagnostic Calibration validation.
Living Document
This document evolves continuously.
Unlike individual framework specifications, Framework Engineering is expected to mature as new frameworks and new Reference Cases reveal better methods for designing analytical systems.
Changes to this document should themselves be evidence-based.