The NATIVE methodology
NATIVE moves a transformation from mandate to merged code to measured operation across six stages — Navigate, Architect, Transform, Integrate, Validate, Evolve. It replaces the ceremonies of Agile and SAFe with engineering-grade gates: every stage has an entry signal, a built artifact, and an exit a practitioner can show you.
Why a methodology at all
Modernized and AI-native systems fail in ways traditional software does not. They regress quietly between model versions, depend on retrieval corpora nobody versioned, and fail probabilistically rather than deterministically. A two-week sprint with a demo at the end exposes none of it.
The frameworks most enterprise teams default to were built around ceremonies — stand-ups, increments, program boards — not around the artifacts this work actually produces: evals, prompts, tool schemas, retrieval indices, canary telemetry, and rollback runbooks.
NATIVE is organized around those artifacts. Each stage is defined by what must be built before the next can begin, and by a gate a practitioner signs. The ceremony is optional. The artifact is not. A stage is not complete because a calendar says so — it is complete because its artifact exists and its gate has been cleared. If the gate fails, the stage re-opens, not the next sprint.
The six stages
A stage is not complete because a calendar says so. It is complete because its artifacts exist and its gate has been signed. If the gate fails, the stage re-opens — not the next sprint.
Locate the real problem, the real owner, and the real data path before a single line of the new system is written.
Choose the model, retrieval, and orchestration shape that fit the constraint — not the one on the vendor slide.
Build the thing against the client's own code, in the client's own repository, where the change can be inspected.
Put the system in the path of a real user behind the team's existing auth, logging, and cost controls.
Prove the business metric moved and prove the failure modes are bounded — with a rollback that has been rehearsed.
Hand the system over with the contracts, evals, and runbooks that keep it honest across model versions.
Structural contrast
The difference between NATIVE, Agile, and SAFe is not tone or vocabulary. It is what counts as progress and what ends the work.
Agile
SAFe
NATIVE
Unit of progress
A story moved to done.
A feature accepted at the increment boundary.
An artifact that passes its stage gate.
Cadence driver
The sprint calendar.
The Program Increment calendar.
The next gate — it lands when the work is ready, not when the timebox ends.
Where failure surfaces
Demo day.
The Inspect & Adapt workshop.
The eval harness, canary telemetry, and drift alerts — continuously.
Shipped between checkpoints
Stories.
Features, enablers, architectural runway.
Prompts, evals, tool schemas, retrieval config, and runbooks — under version control.
Who signs the work off
The product owner.
The release train engineer and business owners.
A practitioner who can be asked to rebuild the artifact on camera.
What ends the engagement
The backlog runs out of priority.
The portfolio decides to fund the next increment.
The internal team can ship the next change without the practitioner.
Operating principles
The six stages describe what gets built. These six principles describe how a practitioner behaves while building it. Both are enforceable.
Every engagement ends in a merged change inside the client's repository. Memos, decks, and readouts are byproducts of the work — never the deliverable. If a practitioner cannot point to the line that changed, the stage has not shipped.
No recurring meeting enters an engagement without a business metric tied to it. Stand-ups and review boards are optional tools, not entitlements. Every cadence carries a named owner and a signal that gets reviewed the following cycle.
Practitioners recommend only what they have shipped production code with recently — nothing older, no vendor slide left untouched. If it has not run under load, it does not enter the client's stack.
Reference implementations are rebuilt against the client's actual data, services, and auth before delivery. A canned walkthrough from a vendor portal is decoration, not proof.
The practitioner contracted is the practitioner on camera. Shadow-delivery is prohibited. If the named operator cannot be present, the session reschedules — clients pay for a person, not a bench.
Client code, prompts, data, and internal context never leave the engagement boundary. Nothing is used to train external models, seed another engagement, or enrich a practitioner's own products. The confidentiality surface is contractual and identical for every client.
Breach of any principle is grounds for recertification review. A practitioner signs to this contract before the first engagement and re-signs at every annual renewal.
The NATIVE page covers what each phase achieves; this page is the delivery discipline behind it. Watch a stage clear its gate in the demo.