Project Phoenix | Principles

Six Principles

1) Write-Then-Verify

Every write action is followed by a read or verify step to confirm success.

2) Abstraction Ladder (V1-V6)

Capabilities are taught progressively: foundation, conditional logic, chaining, natural keys, async, synthesis.

3) Domain Doctor Tool Design

Tools are atomic, single-purpose, and deterministic. State belongs to tools, not the agent.

4) Anti-Hallucination Templates

Reports are generated from structured templates, not freeform text.

5) Test-and-Prove Cycle

Golden files, unit tests, and validation suites prove correctness before release.

6) Human-in-the-Loop Gate (Post-V4)

After natural-key capability, a human reviewer issues binding GO/NO-GO with audit trail before progression.

How To Use Them

These principles are meant to be adapted, not copied mechanically. They are useful when the goal is reliability, auditability, and bounded behavior under real operating constraints.

They are designed for grounded domain tasks — where deterministic substrates exist, the task class is well-defined, and correctness can be verified against real artifacts. In that regime, these principles make the harness the binding constraint. That is their purpose.

Human review is included as a control surface, not as decoration. It matters most once the system is strong enough to produce outputs that can be grounded against real source data and artifacts.