Assessment Criteria & AI-Native Principles¶
Purpose
This page describes the five core principles that distinguish an AI-native approach from traditional software development, and the assessment criteria to determine whether a project falls under these principles.
1. When Does This Apply?¶
A project falls under the AI-native approach when it meets at least two of these three conditions:
| Condition | Description |
|---|---|
| Material Impact | The system influences production outputs, decisions or customer interactions. |
| Context-Driven Behaviour | Inputs that steer behaviour (prompts, RAG sources, fine-tuning data) are actively managed and versioned. |
| Non-Deterministic | The output is probabilistic — the same input can produce different results. |
Once qualified, the five principles below serve as guidance for governance, development and monitoring.
2. The Five AI-Native Principles¶
Principle 1 — Behaviour Steering Over Model Choice¶
The behaviour of an AI system is primarily determined by specifications, prompts and hard boundaries — not by which model runs underneath. Invest in clearly defined expected behaviour before investing in model optimisation.
In practice:
- Write a Goal Card before choosing a model.
- Define Hard Boundaries as non-negotiable constraints.
- Treat prompts as versioned artefacts, not throwaway experiments.
Principle 2 — Proportional Governance¶
The weight of controls, validation and documentation should be proportional to the risk of the system. An internal summarisation tool requires a lighter approach than a customer-facing decision system.
In practice:
- Use the Risk Classification to determine the level (Critical → Low).
- Fast Lane for minimal risk; full lifecycle for high risk.
- Adjust the burden of proof per Gate Review — not every gate requires the same depth.
Principle 3 — Evidence Over Assumptions¶
Every claim about performance, safety or value must be supported by measurable results. Intuition and demos are not evidence; structured tests and validation reports are.
In practice:
- Compile a Golden Set before development.
- Validate at three levels: syntactic (does it work?), behavioural (does it do what's expected?), goal-oriented (does it help the user?).
- Document results in a Validation Report.
Principle 4 — Human in Control¶
AI systems operate within frameworks determined by humans. At higher Collaboration Modes (delegated, autonomous), the frameworks become stricter, not looser.
In practice:
- Every mode has explicit escalation criteria and an emergency stop.
- The Guardian has veto rights when hard boundaries are breached.
- Human-in-the-loop is the default; human-on-the-loop only after explicit approval.
Principle 5 — Continuous Validation¶
AI behaviour changes over time due to data drift, model updates and changing context. Validation is therefore not a one-off activity but an ongoing process.
In practice:
- Set up Monitoring & Drift Detection from day one.
- Repeat Golden Set tests with every significant change.
- Use Retrospectives and Kaizen Logs to continuously improve the approach.
3. Related Modules¶
- AI-Native Definition — what makes a system AI-native?
- Artefact Model — the five managed artefacts
- Validation Model — the three validation dimensions
- Evidence Standards — what must you prove per gate?