Framework Engineering Constitution

Status: Working draft

Purpose: Define the governing principles that Framework Engineering and the frameworks it governs must follow.

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.

Frozen Versions

Published versions are immutable.

A framework version is frozen during evaluation.

Changes are introduced only in subsequent versions.

No Sacred Concepts

No concept is immune from removal.

The framework serves reality.

Reality does not serve the framework.

Appropriate Precision

Frameworks should avoid expressing judgments with greater precision than the available evidence can support.

Numerical values should be used only when they correspond to meaningful, reproducible measurements or when they demonstrably improve decision-making.

When numerical precision cannot be objectively justified, frameworks should prefer:

• categorical assessments
• evidence profiles
• explicit rationale
• qualitative confidence ranges
• reviewer notes
• supporting and opposing evidence

This principle is not anti-math.

Measured values such as latency, pressure, temperature, defect counts, transaction volume, or elapsed time should be represented numerically when appropriate.

The concern is artificial precision in judgments such as:

• quality
• readiness
• confidence
• priority
• severity
• maturity
• diagnostic strength
• framework value

Rich Evidence Over Aggregate Scores

Frameworks should prefer multidimensional evidence profiles over single aggregate scores.

Aggregate scores may be used for summary reporting only when they do not hide material weaknesses, distort interpretation, or replace the underlying evidence.

Single scores should not be used as the primary basis for engineering decisions unless the score is based on reproducible measurement and its limitations are clearly documented.

Implementation Independence

Frameworks shall define their meaning independently from programming languages, file formats, databases, diagramming tools, or software implementations.

Tools, serializations, and renderers may support a framework, but they shall not define it.

A framework should remain usable without specialized software unless the framework's purpose explicitly requires software.

Knowledge Promotion

Purpose

Framework Engineering distinguishes between accepted knowledge, active research, and applications. The discipline advances by promoting ideas through evidence rather than by assertion.

Principle

Ideas begin as observations or hypotheses. They become part of the Foundation only after accumulating sufficient evidence, surviving meaningful challenge, and demonstrating usefulness through replication or repeated validation. Until then, they remain research artifacts and should be treated as provisional.

Applications, including frameworks developed using Framework Engineering, consume and inform the Foundation but do not, by themselves, establish foundational knowledge.

The Foundation is intentionally conservative; research is intentionally exploratory.

Implications

• Separate established principles from active research.
• Clearly identify the status of research artifacts.
• Promote ideas based on accumulated evidence rather than novelty, authority, or popularity.
• Encourage competing hypotheses and adversarial evaluation.
• Preserve historical records of superseded and failed hypotheses when they contribute to understanding.
• Maintain a clear distinction between foundational principles, ongoing research, and practical applications.