SixDriven turns human intent into traceable software through a visible six-layer chain, even when the work uses AI.
Understand the method
Review the full cycle and the purpose of each layer.
See partial adoption
Start with part of the framework without hiding what remains pending.
Review current status
Check what exists today, what remains open, and what is still pre-MVP.
What SixDriven is
SixDriven is a six-layer framework for working with AI without losing traceability, intent, or authority over the process.
It organizes work into an explicit chain, requires artifacts per layer, and uses validators to verify that a change that looks ready is also backed by evidence.
Why it exists
AI can answer quickly, but a convincing answer does not guarantee that a change is ready.
The problems usually appear before merge and long before deploy:
- Specs written after the code to justify what already happened.
- Changes that grow without clear authorization.
- Green tests that do not prove what matters.
- Decisions hidden in prompts or untraceable conversations.
- Drift between what was requested, what was understood, and what was implemented.
The six-layer cycle
Intent → Spec → Context → Contract → Implementation → Integration
Intent
Defines what should change, why it matters, and who accepts the result.
Spec
Turns intent into verifiable requirements, acceptance criteria, and clear limits.
Context
Connects the spec to the reality of the repo, its constraints, and its current state.
Contract
Defines what must hold for the expected behavior to count as valid.
Implementation
Materializes the change without breaking traceability back to earlier layers.
Integration
Verifies that the change holds inside the real system.
What SixDriven controls
SixDriven aims to prevent false greens.
A false green happens when something looks correct because the tests pass, but the full chain has not been verified.
To reduce that risk, the method requires explicit controls:
- Each layer must have its artifact.
- Handoffs must match the layer before and after.
- Promotion decisions must exist.
- Evidence must be explicit.
- Drift must remain visible.
- Unknowns must not be presented as confirmed.
What stays in the repo
The result is not only code.
The repo also keeps artifacts that let you recompute why the change exists and how it was verified:
- intent
- spec
- context
- contract
- implementation
- integration verification
- checkpoints
- promotion decisions
- recomputable evidence
Current status
SixDriven is in pre-MVP stage. There is already a functional core with validators, artifacts, and reference slices. There is also active work in the dashboard and runtime.
It is not a finished product yet. The current priority is to harden the method, reduce drift, and make the process clearer to use.