DECISION: [ADR-000] Analysis Framework as Governing Methodology
DATE: 2026-02-18
TYPE: 1 (irreversible)
STATUS: Accepted
SOLITON SCORE: 0.90

## Context

Orxaq requires a governing methodology that spans software architecture, regulatory
compliance, causal inference, and operational excellence. No single existing framework
covers all requirements. A systematic analysis of frontier frameworks is needed to
synthesize the best practices into a coherent methodology.

## Analysis Framework

### Part I: Frontier Frameworks Surveyed

Twelve frameworks were evaluated across software engineering, systems engineering,
organizational performance, and regulatory compliance:

1. **NASA Systems Engineering Handbook** — Mission-critical systems engineering with
   formal verification, requirements traceability, and failure mode analysis. Strong
   on safety and auditability; weak on agility and software-specific practices.

2. **INCOSE Systems Engineering Body of Knowledge** — Comprehensive SE lifecycle from
   concept through disposal. Strong on stakeholder analysis and interface management;
   heavy process overhead for small teams.

3. **SpaceX Iterative Hardware Development** — Rapid prototyping with build-fly-learn
   cycles. Strong on velocity and learning from failure; assumes hardware where rollback
   is impossible (software can roll back).

4. **DORA (DevOps Research and Assessment)** — Empirically validated metrics: deployment
   frequency, lead time for changes, change failure rate, time to restore service, and
   reliability. Only framework with statistical backing for performance correlation.

5. **TOGAF (The Open Group Architecture Framework)** — Enterprise architecture with ADM
   cycle. Strong on stakeholder communication; heavy governance overhead, architecture
   astronaut risk.

6. **Zachman Framework** — 6x6 matrix ensuring completeness across What/How/Where/Who/
   When/Why dimensions and Contextual/Conceptual/Logical/Physical/Detail/Functioning
   perspectives. Completeness check, not a process.

7. **Architecture Decision Records (ADRs)** — Lightweight decision capture with context,
   options, decision, and consequences. Strong on traceability; no built-in scoring or
   machine-readability.

8. **Google SRE (Site Reliability Engineering)** — Error budgets, SLOs, toil reduction,
   blameless postmortems. Strong on operational excellence; assumes large-scale
   distributed systems infrastructure.

9. **Amazon Two-Pizza Teams / Working Backwards** — Type 1/Type 2 decisions, PR/FAQ
   process, small autonomous teams. Strong on customer focus and decision velocity;
   assumes organizational scale.

10. **Toyota Production System (Lean)** — Continuous improvement (kaizen), waste
    elimination, just-in-time, jidoka (automation with human touch). Strong on flow
    optimization; manufacturing metaphors require translation.

11. **NIST Cybersecurity Framework** — Identify, Protect, Detect, Respond, Recover.
    Strong on security posture assessment; compliance-focused, not development-focused.

12. **C4 Model (Simon Brown)** — Context, Container, Component, Code diagrams. Strong
    on multi-level visualization; diagrams only, no process or methodology.

### Part II: Scoring Matrix

Each framework scored on 5 axes (0-10):
- **Causal Rigor**: Can it model cause-effect relationships?
- **Regulatory Fit**: Does it support SR 11-7, CECL, CCAR compliance?
- **Agility**: Can it support rapid iteration?
- **Auditability**: Does it produce examinable artifacts?
- **Scalability**: Does it work from 1-person to 100-person teams?

| Framework | Causal | Regulatory | Agility | Audit | Scale | Total |
|-----------|--------|------------|---------|-------|-------|-------|
| NASA SE | 6 | 8 | 3 | 9 | 4 | 30 |
| INCOSE | 5 | 7 | 3 | 8 | 5 | 28 |
| SpaceX | 4 | 3 | 9 | 4 | 6 | 26 |
| DORA | 3 | 5 | 8 | 7 | 9 | 32 |
| TOGAF | 4 | 6 | 4 | 7 | 7 | 28 |
| Zachman | 7 | 7 | 5 | 8 | 6 | 33 |
| ADRs | 5 | 8 | 9 | 9 | 8 | 39 |
| Google SRE | 3 | 4 | 7 | 6 | 8 | 28 |
| Amazon | 4 | 3 | 8 | 5 | 7 | 27 |
| Toyota | 5 | 4 | 7 | 5 | 7 | 28 |
| NIST CSF | 2 | 9 | 4 | 9 | 7 | 31 |
| C4 Model | 3 | 3 | 8 | 6 | 8 | 28 |

No single framework scores above 40/50. ADRs score highest but lack measurement
and causal modeling. A synthesized approach is required.

### Part III: Seven Synthesized Practices

From the 12 frameworks, 7 practices are synthesized:

1. **Decision-First Architecture** (from ADRs + Amazon Type 1/2)
   Record every architectural decision before implementing it. Classify as
   Type 1 (irreversible, high ceremony) or Type 2 (reversible, lightweight).
   Extended with Soliton Scores for confidence quantification.

2. **Build-Fly-Learn Cycles** (from SpaceX + Toyota Kaizen)
   Short iterations where each cycle produces working code, measured results,
   and documented learnings. No phase gates without running software.

3. **Competency-Mapped Roles** (from NASA + INCOSE)
   Every task requires specific competencies. Map roles (Operator, Conductor,
   Worker, Specialist) to competency requirements. No task executes without
   the required competency available.

4. **Five-Metric Measurement** (from DORA + Soliton)
   Track 5 DORA metrics plus Soliton Reliability as 6th:
   - Deployment Frequency
   - Lead Time for Changes
   - Change Failure Rate
   - Time to Restore Service
   - Reliability (availability)
   - Soliton Score (causal path resilience)

5. **Zachman Completeness Checks** (from Zachman Framework)
   Before any component is "done," verify it answers all 6 questions
   (What/How/Where/Who/When/Why) at the appropriate abstraction level.

6. **Risk-Tiered Security** (from NIST CSF + SR 11-7)
   All data classified by sensitivity. All operations audited. Security
   controls proportional to risk tier. Hash-chained audit log from day one.

7. **Multi-Level Visualization** (from C4 + TOGAF)
   System documented at Context, Container, Component, and Code levels.
   Each level has a target audience and appropriate detail.

### Part IV: Expertise Domains Mapped to Roles

14 domains required for Orxaq, mapped to role hierarchy:

| Domain | Primary Role | Backup |
|--------|-------------|--------|
| Causal Inference | Conductor | Specialist |
| Credit Risk Modeling | Specialist | Conductor |
| Regulatory Compliance | Operator | Conductor |
| Systems Engineering | Conductor | Worker |
| Software Architecture | Conductor | Worker |
| Data Engineering | Worker | Specialist |
| Statistical Methods | Specialist | Conductor |
| Machine Learning | Specialist | Worker |
| Security Engineering | Worker | Conductor |
| DevOps/SRE | Worker | Conductor |
| API Design | Worker | Conductor |
| Visualization | Worker | Specialist |
| Documentation | Worker | Conductor |
| Testing/QA | Worker | Conductor |

### Part V: Self-Referential Substrate Design

The Analysis Framework governs itself. When evaluating the Analysis Framework:
- Apply Zachman completeness to the framework itself
- Measure the framework's DORA metrics
- Record framework evolution decisions as ADRs
- Score framework resilience via Soliton

This creates a self-improving loop: the methodology improves the methodology.

### Part VI: Initial ADRs

ADR-001 through ADR-005 derive directly from this analysis:
- ADR-001: Why synthesize rather than adopt one framework
- ADR-002: Why DORA metrics specifically
- ADR-003: Why extend ADRs with machine-readable fields
- ADR-004: Why Build-Fly-Learn over waterfall
- ADR-005: Why seam-spec for non-load-bearing dimensions

## Decision

Adopt the Analysis Framework as the root governing methodology for all Orxaq
architectural and engineering decisions.

## Rationale

No single framework covers causal inference + regulatory compliance + agile
development + auditability. The synthesized approach draws from empirically
validated practices (DORA), safety-critical engineering (NASA), and lean
manufacturing (Toyota) to create a methodology suited to causal AI for
credit risk — a domain that demands both innovation velocity and regulatory rigor.

## Consequences

**Easier:**
- Every decision has a documented rationale
- New team members can trace why things are built the way they are
- Regulators can audit the decision chain from framework to code
- Self-referential improvement catches methodology drift

**Harder:**
- Higher upfront ceremony per decision (mitigated by Type 2 classification)
- Framework itself must be maintained and versioned
- Onboarding requires understanding the meta-framework
