The NATIVE Framework

A delivery framework for
AI that ships.

NATIVE is six stages — Navigate, Architect, Transform, Integrate, Validate, Evolve — that move an enterprise AI initiative from mandate to merged code to measured operation.

It replaces the program-management rituals of SAFe with engineering-grade checkpoints. Every stage has an entry signal, a built artifact, and an exit gate that a practitioner can show you.

Read the six stagesHow it differs from Agile & SAFe

Why a new framework

Agile was written for web software. SAFe was written for coordinating committees. Neither was written for AI.

AI systems fail in ways traditional software does not. They regress silently between model versions. Their answers depend on retrieval corpora nobody versioned. Their failure modes are probabilistic, not deterministic. A two-week sprint with a demo at the end does not expose any of this.

The frameworks most enterprise teams default to were built around ceremonies — stand-ups, increments, program boards — not around the artifacts AI work actually produces: evals, prompts, tool schemas, retrieval indices, canary telemetry, rollback runbooks.

NATIVE is organised around those artifacts. Each stage is defined by what must be built before the next stage can begin, and by a gate a practitioner signs off. The ceremony is optional. The artifact is not.

Section 01 — The framework

Six stages. Every one has a gate.

A stage is not complete because a calendar says so. It is complete because its artifact exists and its gate has been signed. If the gate fails, the stage is re-opened — not the next sprint.

  1. N

    Navigate

    Locate the real problem, the real owner, and the real data path before a single token is generated.

    Entry signal
    An executive mandate, a funded budget, or a board-level ask that has not yet been translated into an engineering scope.
    What gets built
    • One-page problem frame with the business metric under attack
    • Named accountable owner on the client side and on the delivery side
    • Map of the systems, data, and auth boundaries the work will touch
    Exit gate
    The problem can be described in one sentence and pointed to in one repository.
  2. A

    Architect

    Choose the model, retrieval, and orchestration shape that fit the constraint — not the one on the vendor slide.

    Entry signal
    A scoped problem with a known metric and a named owner.
    What gets built
    • Reference architecture drawn against the client's actual stack
    • Shortlist of models and tools the team will evaluate, with rejection criteria
    • Threat model and data-handling contract for anything crossing the boundary
    Exit gate
    A senior engineer outside the engagement could rebuild the plan from the diagram and the constraints.
  3. T

    Transform

    Build the thing. On camera. Against the client's code. In the client's repository.

    Entry signal
    An agreed architecture and a baseline to beat.
    What gets built
    • Working implementation in a feature branch of the client's repo
    • Prompts, tool schemas, and retrieval config under version control
    • Eval harness that runs locally and in CI against a held-out set
    Exit gate
    A pull request exists. Tests pass. The eval harness beats the documented baseline.
  4. I

    Integrate

    Put the system in the path of a real user behind the team's existing auth, logging, and cost controls.

    Entry signal
    A merged or merge-ready pull request with a green eval harness.
    What gets built
    • Production-path integration behind the client's auth, quotas, and observability
    • Cost and latency dashboards wired to the same place the team already watches
    • Feature flag or canary gate so the rollout is reversible
    Exit gate
    One real user — internal or external — has used the system end-to-end through production plumbing.
  5. V

    Validate

    Prove the business metric moved, and prove the failure modes are bounded.

    Entry signal
    A live system with real traffic, even if small.
    What gets built
    • Before/after read on the business metric the project was scoped against
    • Drift, hallucination, and cost regressions captured as alerts, not dashboards
    • Rollback runbook that a second-line engineer can execute without the original author
    Exit gate
    The change to the business metric is measurable, and the rollback has been rehearsed.
  6. E

    Evolve

    Hand the system over with the contracts, evals, and runbooks required to keep it honest across model versions.

    Entry signal
    A validated system and a team that will own it after the practitioner leaves.
    What gets built
    • Owner's manual — what to re-run when a model, prompt, or index changes
    • Regression suite the internal team can extend without the practitioner
    • Quarterly review contract that revisits the business metric, not just uptime
    Exit gate
    The internal team can ship the next change to the system without calling the practitioner back.

Section 02 — Structural contrast

Why NATIVE is not a rebranded sprint.

The difference between NATIVE, Agile, and SAFe is not tone or vocabulary. It is what counts as progress and what ends the work.

  • Unit of progress
    A story moved to done
    A feature accepted at the PI boundary
    An artifact that passes its stage gate
  • Cadence driver
    Sprint calendar
    Program Increment calendar
    The next gate — which lands when the work is ready, not when the timebox ends
  • Where failure surfaces
    Demo day
    Inspect & Adapt workshop
    Eval harness, canary telemetry, drift alerts — continuously
  • What the team ships between checkpoints
    Stories
    Features, enablers, architectural runway
    Prompts, evals, tool schemas, retrieval config, 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
    Backlog runs out of priority
    Portfolio decides to fund the next PI
    The internal team can ship the next change without the practitioner

Section 03 — Operating principles

The contract under every stage.

The six stages describe what gets built. These six principles describe how a certified practitioner behaves while building it. Both are enforceable.

  1. 01

    Ship, don't summarize.

    Every engagement ends with a merged pull request in the client's repository. Memos, decks, and readouts are artifacts of the work — never the deliverable. If the practitioner cannot point to the line of code that changed, the stage has not shipped.

  2. 02

    Measurable over ceremonial.

    No recurring meeting enters an engagement without a business metric tied to it. Stand-ups, retros, and review boards are optional tools — not entitlements. Every cadence carries a named owner and a signal that gets reviewed the following cycle.

  3. 03

    Current tools only.

    Practitioners recommend tools they have personally shipped production code with recently — nothing older, no vendor slides untouched. If it has not been used under load, it does not enter the client's stack.

  4. 04

    Client stack, not vendor stack.

    Examples, labs, and reference implementations are rebuilt against the client's actual data, services, and auth before delivery. Canned walkthroughs from a vendor portal are decoration, not training.

  5. 05

    Named accountable operator.

    The practitioner contracted is the practitioner on camera. Junior shadow-delivery is prohibited. If the named operator cannot be present, the session reschedules — clients pay for a person, not a bench.

  6. 06

    Transparent IP handling.

    Client code, prompts, data, and internal context never leave the engagement boundary. Nothing is used to train external models, seed other engagements, or enrich the practitioner's own products. The confidentiality surface is contractual and identical for every client.

Breach of any principle is grounds for recertification review. The practitioner signs to this contract before their first engagement and re-signs at every annual renewal.

Get involved

Two ways in.

NATIVE is operated by certified practitioners and bought by enterprise teams tired of shipping decks.

Practitioners

Become a certified practitioner

Qualified enterprise engagements, procurement handled, the NATIVE framework as your operating contract. Open to hands-on senior engineers shipping AI in production.

Apply for certification

Enterprises

Hire a certified practitioner

A NATIVE residency. Practitioners embed with your engineering team, co-ship one production AI feature through all six stages, and certify your engineers along the way.

Request an engagement