Instant by Falcra
How trusted enterprise software gets built in days, not weeks or months
The Instant Framework is how enterprises build world-class software with the AI-Driven Development Lifecycle. For a few days, the people who decide, from business experts to managers to the technical team, sit in one room while an AI takes the work from requirements to tested software. They react, they decide, and every decision is recorded. All in a few days. And Instant guides them through this complex process.
This isn't AI-assisted coding. The AI drives the whole lifecycle, an approach that has already saved millions of dollars in licence fees. Instant makes it streamlined and safe, and it is free to use under the Creative Commons Attribution licence.
This guide explains what Instant is, how an engagement runs and how the work is signed off, for the people who approve it as much as those who do it.
The Instant Framework is published in three parts: the Manifesto (values and principles), the Guide (what Instant is, its roles, stages and gates) and the Practices (how its decisions, foundations, assurance and AI rules work in detail).
Published by Falcra. Instant was created by Drew Salem, founder of Falcra.
The Instant Framework (theinstantframework.com) by Falcra (falcratechnologies.com)
Instant in brief
Instant goes hand in hand with the AI-Driven Development Lifecycle, which chapter 2 explains in more detail. It brings the people who know the business, the people who sign off and the people who build into one room for a few days. An AI drives the lifecycle while they watch, and every decision and every piece of evidence is recorded along the way.
Instant is a framework for building enterprise software in days instead of months, with the AI-Driven Development Lifecycle (AI-DLC). Its purpose is to speed up building software by doing it together, while still going through the stages, and under the governance, of the regular software development lifecycle. Nothing is skipped. It simply happens in days, not months.
On a traditional project, an analyst spends weeks with your experts writing requirements. Documents travel between groups. Developers build from those documents. Instant replaces that chain with one room. For a few days, every role sits together: your subject-matter experts, your managers, your testers, a technical business analyst who drives the AI, and a Challenger who questions the room. Together they take an AI build tool through the whole lifecycle, from the first statement of the problem, through requirements, design and build, to testing.
The AI does the building while the room watches. People react to working software, not to documents. Because the software is built in small increments, there is always something new to react to: the requirements, how a feature should work, what a screen shows, and even details such as colours and where things sit on the screen. They debate it out and decide on the spot. We call these instant feedback loops.
Speed on its own isn't enough for an organisation that has to answer to a board, an auditor or a regulator. So every decision is recorded, and every piece of AI-written code is backed by evidence that your business owner and your technical owner sign. That evidence is what lets you trust software that nobody typed by hand.
A working room, not a waiting room
All of this happens in a few days, with everyone in one room. That doesn't mean a few days of watching a screen. The AI takes time to work: minutes for a change, longer for larger jobs such as a data migration. While it works, people get on with their own work in the room, email and calls included, and turn back to the screen when the Conductor has something to react to. What matters is that the people who decide are there when a decision is needed.
Instant currently runs on AWS's open-source AI-DLC. Only the build engine is AI-DLC. The finished application has no dependency on AI-DLC or AWS.
How to read this guide
Instant is published in three parts: the Instant Manifesto (values and principles), this Guide (what Instant is, its roles, stages and gates), and Instant Practices (how its decisions, enterprise foundations, assurance and AI rules work in detail). Each chapter opens with a short summary. If you are short of time, read the summaries, then chapter 3 and chapter 6: what Instant adds, and how an engagement runs.
The guide is written for everyone involved, business and technical, in plain language. It defines Instant's own terms and leaves out what your professionals already know. It describes a lot of detail, but most of it happens in parallel, in the room, over a few days.
Why Instant exists
Software projects are slow because of the waiting between people, not because typing code takes long. AI coding tools speed up the typing and leave the waiting alone. Mixing the old way of working with the new doesn't make the most of AI; it just slows it down. What is the point of lightning-fast code if everything around it stays slow? Instant removes the waiting, and answers the question AI raises: who stands behind code nobody wrote?
The old way is slow
Whether a project follows Waterfall, Agile or any other delivery framework, it usually begins the same way. A business analyst spends weeks with your experts, writing down what the software should do. Only then does anyone build.
The developers who build it work from documents, not from the people who know the business. When they have a question, it goes back up the chain, and the answer can take days, and even weeks. Misunderstandings stay hidden until users finally see the software. By then they are expensive to fix.
Agile is no longer agile enough
Agile shortened the cycle. It did not remove the waiting. Sprints still wait on documents, on hand-offs between groups, and on sign-offs from people who were not part of the conversation. The work moves in short bursts, but the delays between the bursts remain.
AI-assisted development alone doesn't fix it
Most organisations know AI-assisted development: developers using an AI coding assistant to write code far faster than a person can. But writing code is only one part of delivering software. Requirements still have to be agreed, designs still have to be approved, and results still have to be tested and signed off. If those steps stay slow, the project stays slow. Speeding up the coding alone leaves the rest of the process just as slow.
Researchers call this the AI productivity paradox. Developers write more code with AI assistants, yet their organisations deliver no faster. In a 2025 controlled study by METR, experienced developers using AI tools took about 19% longer to finish their tasks, while believing they had been quicker.
AI-driven development changes the lifecycle
AWS describes two extremes in how organisations use AI today. At one end, AI-assisted development speeds up individual tasks but keeps the traditional lifecycle, and its delays. At the other, AI-autonomous development expects the AI to build whole applications with no one involved, which leaves nobody able to explain or vouch for what was built. Until recently there was nothing in between.
The AI-Driven Development Lifecycle, defined by AWS, is that middle ground. The AI drives every stage, from requirements and design to build and test, and people direct it and decide at each step. That is what turns months into days, and it has already been used to save millions of dollars in software licence fees. It also brings new pitfalls: features nobody asked for, guesses presented as facts, and code nobody has read. Instant is how an organisation runs AI-driven development well: the room, the roles, the sign-offs and the guardrails that make it streamlined and keep it safe.
Instant shortens the whole lifecycle, not just the coding.
Working with an AI build tool is like working with an exceptionally gifted colleague who takes everything literally and knows nothing about your business. It works at extraordinary speed and is often brilliant. But wherever the instructions leave a gap, it fills the gap with a confident assumption and presents it as fact, usually without telling you.
Those assumptions then compound. The AI writes them into its own documents, reads them back later as if they had been agreed, and builds new assumptions on top, until a single guess has hardened into part of the foundation. By the time anyone notices, often hours later, unpicking it is slow.
Instant keeps this in check. Clear instructions and small steps; every assumption labelled as an assumption until a person confirms it, and never built on before then (Practices, chapter 4); and people watching what the AI does at every stage.
Guardrails built in for AI-written code
AI brings new risks along with its speed, and Instant is built to guard against them. When a person writes code, that person understands it. When an AI writes it, nobody does fully, and it arrives faster than people can read it, so the usual safeguard of a colleague reviewing every change can't keep up. Instead, Instant proves the code with evidence, risk-tiered human review and checks that are shown to work. Practices, chapter 3 explains how.
What Instant adds
AI-DLC drives the lifecycle. Instant comes hand in hand with it, adding how your organisation decides, trusts and signs off what the AI builds. Four things set it apart.
AI-DLC is a workflow that walks an AI through the stages of building software. It is good at that. What it doesn't do for you is decide how your organisation will govern the result. Instant is built around that gap.
Assurance and the evidence pack
AI-written code raises the question: who signs off code nobody wrote? Instant answers it with a risk-tiered set of controls that ends in a signed evidence pack, instead of a waiver. Practices, chapter 3 explains it in full.
Business-led, not developer-led
Your experts and business owners are in the room for the whole working session. They own the requirements, write the acceptance tests and co-sign go-live. The people who know the business decide what the software does.
A guess is never a fact
AI can state a guess with complete confidence. Instant's standing rules for the AI force it to show where every claim came from, to treat an unchecked field name as unverified, and to report blocked work as blocked. Practices, chapter 4 explains the rules.
Enterprise decisions built in
Decisions that large organisations always face are made early and on purpose: how much change history (audit trail) the application keeps, how people sign in, how any existing data moves across, and which security rules the build must never break. Practices, chapters 1 and 2 cover them.
Names
Instant is the framework. Mob is the method, Blitz is the working session, and the roles are Conductor, Challenger, Scorekeeper and Roadie, with an optional Stage Manager. Where AWS's AI-DLC already has a term, Instant uses it, credited to AWS.
Instant uses a small set of names. They are worth learning, because the rest of this guide uses them.
| Name | What it is |
|---|---|
| Instant (the framework) | The whole way of working described in this guide. The name was chosen to suggest speed. Like Agile, it is unowned: anyone may use it. This guide is published by Falcra under the Creative Commons Attribution-NoDerivatives 4.0 licence (CC BY-ND 4.0): free to share and use, including commercially, with credit to Falcra and no changes. The full notice is at the end of this guide. |
| Mob (the method) | Every role working together with the AI, in one room. |
| Blitz (the working session) | Two to four consecutive days in which the room takes the AI build tool through the lifecycle, or the same work split into shorter sessions. |
| Conductor (the technical business analyst) | Drives the AI build tool while the room watches. |
| Challenger (the facilitator) | Questions the room so the loudest voice doesn't win. Often a business analyst, but needn't be. |
| Scorekeeper (the note-taker) | Records your experts' feedback. |
| Roadie (the developer) | On call, not building: environments, security and build problems. |
| Stage Manager (the project manager) | Optional. Clears the path to production. |
| Stages S0 to S6 | The seven stages of an engagement, from Prepare (S0) to Release (S6). "S" numbers are always stages. |
| Gates G1 to G4 | The four formal sign-offs. The work can't pass a gate until named people approve it. "G" numbers are always gates. |
| Tweak | A small cosmetic change asked for in the room, such as a colour, label or spacing. Accepted on screen, with no story or pull request of its own. Not to be confused with a Bolt, which builds something. A tweak that changes behaviour is a rule, not a Tweak. |
| The crew | The Conductor, Challenger, Scorekeeper and Roadie, whoever supplies them. |
| You, your | Your organisation: the one the application is built for. Where a decision is yours, the guide names the role that makes it. |
"Mob" follows AWS's own use of Mob Elaboration and Mob Construction in AI-DLC, where the team works through requirements and the build with the AI in real time. Instant keeps the same room together, business experts included, from framing the Intent through to the build.
Terms Instant takes from AWS
Where AWS's AI-DLC already has a term, Instant uses it and credits AWS. Instant gives its own names only to what it adds. The terms describe ideas, not features of one tool, so they still make sense if the engine changes. AI-DLC's phases are the exception: they are the engine's own structure, so Instant maps onto them rather than adopting them.
| Term (from AWS) | What it means in Instant |
|---|---|
| Intent | The goal the business wants to achieve, stated in business terms. Everything built traces back to it. It is captured in Instant's Frame stage. |
| Unit of Work | A self-contained piece of the application, built and reviewed as one. The AI proposes the units from the stories, and the room approves them. |
| Bolt | A short build cycle, hours or days rather than weeks, that delivers part of a unit. The AI proposes the Bolts and the room approves them. A Blitz contains several Bolts. |
| Mob Elaboration | The room turning the Intent into stories and units with the AI, in real time. In Instant, this is Specify and Design. |
| Mob Construction | The room building with the AI, in real time. In Instant, this is Build. |
| Ideation, Inception, Construction, Operation | AI-DLC's phases. They are used only to map Instant's stages onto the current engine, AWS's AI-DLC (chapter 8). They are not part of Instant's definition. |
Instant has many more terms of its own, for its roles, stages, sign-offs and artifacts. Each is introduced in the chapter where it is used, and all are collected in the glossary (chapter 11). Chapter 7 describes the roles in full.
The Manifesto
Six values sum up what Instant stands for. Ten principles sit beneath them, and decide any situation the rules don't cover. Both are published as the Instant Manifesto.
The Instant Manifesto
Published by Falcra.
We are building software with the AI-Driven Development Lifecycle, and helping others do the same. Through this work we have come to value:
- Everyone in one room over handoffs between teams
- Reacting to working software over reviewing documents about it
- Decisions made on the spot by their owners over decisions waiting for the next meeting
- Business-led over developer-led
- Evidence that it works over reading every line of code
- Verified facts over confident guesses
What comes after "over" still matters. We value what comes before it more.
The ten principles behind these values are set out with the manifesto: read the principles.
The engagement
An Instant engagement has three stretches: a short lead-up of preparation, a Blitz of two to four days with everyone in one room, either consecutive or split into shorter sessions, and then proving, releasing and refining the result.
A short lead-up
Business analyst groundwork before the Blitz: your existing documentation collected, the brief, the readiness checklist, who signs off, your own rules, and the crew.
2–4 days, together or in sessions
Every role in one room runs the AI build tool through Frame, Specify, Design and Build.
After the Blitz
Build finishes, your experts test, the evidence pack is signed, and one or two experts stay on to refine.
Preparation
A business analyst spends a short period, one to two weeks, getting everything ready, so that no Blitz day is lost to something that could have been settled earlier. Preparation produces:
- Your existing documentation, collected. There is often a lot of it from earlier work, such as business requirements documents (BRDs), non-functional requirements (NFRs), entity relationship diagrams (ERDs), graphs, documents on existing systems and processes, and existing diagrams and designs. The Challenger sorts it by stage, so the AI build tool gets what each stage needs. It doesn't replace the stages: the AI build tool still takes the room through each one and suggests the requirements, design and the rest, but its suggestions are better informed by the work already done.
- A brief describing what you want to build and why.
- A readiness checklist, so you can see what has to be in place before the Blitz.
- Your security constraints package, if you want one (Practices, chapter 1).
- An agreed approach to assurance, with the people who will sign the evidence pack named.
- Your own change-control and audit rules, gathered, so the build respects them.
- Recording and transcription arranged for every session, with everyone's agreement.
- The crew chosen with you (chapter 7).
Preparation is also when long-lead items get started, because they take time to arrange inside a large organisation: environments for development, testing and production, access for the Roadie, the person in IT who will set up sign-in, and your data-handling approach. Where the new application replaces a system that holds data, it is also when a backup is confirmed and read-only database access is requested, ideally a direct read-only connection the AI can query itself (Practices, chapter 2).
The Blitz
For two to four days, every stakeholder is in one room. The Conductor drives the AI build tool. The room watches the results appear, reacts, debates and decides.
It is a working room. While the AI is working, people carry on with their own work at the table, and the Conductor calls the room back when there is something to see or decide. Nobody has to give up their day job to take part; they need to be present when their decisions come up.
The Blitz covers four stages: Frame, Specify and Design (together, Mob Elaboration: the room works out the requirements and design with the AI) and the first Bolts of Build (Mob Construction: the room builds with the AI). Chapter 8 describes each stage. Early on, the AI turns what the room has said into a requirements document, and the business reviews it there and then. Your experts decide what appears on screen, when, and under what circumstances.
The sign-off timeline (chapter 8) can be on screen throughout, so everyone can see which sign-offs are done and which are next.
The Scorekeeper records your experts' feedback as it happens. Anything the room can't settle on the spot, such as a question nobody present can answer, is noted and fed to the AI build tool afterwards.
Every Blitz session, and every session with your experts, is recorded in Teams and transcribed. This isn't optional: the transcripts are cross-checked against the Scorekeeper's notes and given to the AI build tool whenever it needs to clarify something, so nothing said in the room is lost. Everyone taking part agrees to recording during preparation (chapter 9).
Consecutive days, or split into sessions
Consecutive days are the default, because momentum is highest and nothing is forgotten overnight. But everyone has a day job, so the Blitz can be split into shorter sessions instead. Each session ends at a sign-off, so every session finishes with a decision made, not with work left half done.
| Session | Stages | Ends with | Who's needed |
|---|---|---|---|
| 1 | Frame and Specify | G1 Spec agreed | Everyone. This is where the debate happens. |
| 2 | Design | G2 Ready to build | The Conductor, Challenger and Roadie, and the experts for screens and rules |
| 3 onward | Build, Bolt by Bolt | G3 for each unit | The Conductor, and the experts who decide what appears on screen |
A split Blitz works when it keeps to a few rules:
- Stop only at a sign-off, never part-way through a stage.
- Keep the gaps short, a week at most, so momentum and the reasons behind decisions aren't lost.
- The same people come back for every session they are needed in, with no stand-ins, or decisions get reopened.
- Use the gaps. Questions the room couldn't answer are settled between sessions, so nothing is left waiting at the next one.
- Pick up exactly where you left off. Each session starts with the Conductor confirming which stage the AI build tool is at.
A split Blitz also asks less of each expert: one full session and some shorter ones, rather than every day. You choose the format during preparation.
After the Blitz
Building continues beyond the Blitz where the application needs it. Before go-live comes the proving stage: your experts' acceptance tests, user acceptance testing, and the signing of the evidence pack by your business owner and technical owner. Then the application goes live.
One or two of your experts stay available afterwards to refine the build. What they learn feeds back into the framing of the next change, so the loop continues.
Roles
Some people are in the room for the whole Blitz and others support it from outside. The Conductor is a technical business analyst, because the AI's questions need technical understanding and knowledge of your business at the same time. The Challenger needs questioning and facilitation skills, not technical ones.
In the room for the whole Blitz
Around the room
The crew
Conductor
A technical business analyst
Drives the AI build tool while the room watches the results live, and answers the tool's questions. Also runs reviewers' questions on the build machine and posts the answers (Practices, chapter 3). Because the AI does the building, the Conductor doesn't need to be a developer, but does need to understand both the technology and the business.
Challenger
A facilitator, often a business analyst; needn't be technical
Questions and challenges the rest of the room, so that the loudest voice doesn't win and weak assumptions get tested. Helps your experts shape their requirements, but doesn't own them.
Scorekeeper
A note-taker
Records your experts' feedback in a feedback file. Anything the room can't resolve on the spot goes to the AI build tool later.
Roadie
A developer, on call, not building
Sets up the development and user-acceptance environments, handles security requirements, and fixes the build problems the AI can't resolve. Also sets up the automated checks that block bad changes, and oversees code reviews in Git: the AI reviews each change the Instant way (Practices, chapter 3), but a developer still oversees it. Questions about the code go back through the Conductor.
Your people
Your experts
In the room for the whole Blitz. They own the requirements. They decide what appears on screen, when, and under what circumstances, down to the colour of a button that shows a status. They write the acceptance tests.
Managers and testers
In the room for the whole Blitz, so that decisions about priorities and testing are made where the work is happening.
Business owner
Signs the evidence pack to say the software behaves as the business needs.
Technical owner
Signs the evidence pack to say the evidence is complete and the controls worked.
Why the Conductor must be technical. The AI build tool's questions often need technical understanding and knowledge of your project at the same moment. A developer without the project background can't answer them. A facilitator without technical depth can't answer them either. That is why the Conductor is a technical business analyst. The Challenger's job is to question the room, which takes facilitation skill rather than technical depth.
Choosing a crew
There are three ways to staff the crew. You choose the best fit during preparation.
Combined
One technical business analyst is both Conductor and Challenger. The smallest crew, and it relies on finding one person with both skills.
Split
A technical business analyst as Conductor, and a separate Challenger, often a business analyst, who needn't be technical. Two people share the load, and each can concentrate on one job.
Developer Conductor
A developer conducts, and is in the room for the whole Blitz.
The Roadie can't be the Conductor. The Roadie isn't in the room. A developer who missed the Blitz would need weeks of documentation to catch up, and that is the delay Instant exists to remove.
The Stage Manager (Project Manager)
On a build that takes days, tracking progress matters less. What matters is clearing the path to production. The Stage Manager does that. Any crew option can add one.
The Stage Manager keeps the board and the governance calendar. They start long-lead requests during preparation and schedule the sign-offs, chasing the people who must give them. They sign nothing themselves. They own risks, issues and dependencies, report to your steering committee, and coordinate the change request, cutover and hypercare. They are in the room for Frame and for a short wrap-up at the end of each day. They don't drive the AI build tool, and they don't decide requirements.
| Situation | Who does it |
|---|---|
| Small, low-risk engagement | The Conductor or Challenger covers it |
| You already have a project manager | Your project manager, with the delivery backlog template and a one-page brief |
| Large or regulated organisation with many forums | A dedicated Stage Manager |
Stages, gates and artifacts
Seven stages, numbered S0 to S6, take an engagement from preparation to release. Every stage ends with a person approving the work or asking for changes. Four of those approvals are gates, numbered G1 to G4: formal sign-offs the work can't pass without named approvers.
Stage and sign-off labels are working labels and may change.
The seven stages
Each stage below lists who leads it, what it covers, and which of your existing documents are given to the AI build tool, when and by whom. The AI is given only what the stage needs: it re-reads everything it holds on every pass, so focused material keeps it fast and accurate. Techniques such as decision tables, risk tiers and the data architecture questions are supplied: the AI drafts them from the discussion and the crew walks the room through them. Nobody needs to know them beforehand.
Every step in order, with who leads it and when it's done: the Instant run sheet.
Prepare
- Led by the Challenger, with the Stage Manager if you have one.
- Brief, readiness checklist, crew option and Blitz format agreed.
- Assurance approach agreed, and the evidence pack signatories named.
- Your change-control and audit rules gathered; the security constraints package written, if you want one.
- Transcript recording arranged and long-lead requests started (chapter 6).
Your documents: the Challenger collects your existing material, such as the business case, process maps, policies, current requirements, the reports and forms the application replaces, and your architecture, security and coding standards, along with documentation from earlier work: BRDs, NFRs, ERDs, graphs, documents on existing systems and processes, and existing diagrams and designs. The Challenger decides which stage each belongs to.
Ends with the readiness checklist complete.
Frame
- Led by the Conductor, with the whole room.
- The Intent of the build, its scope, who is involved, the constraints and what "done" means. Everything later is checked against this.
Your documents: the brief and the business case or problem statement, given to the AI by the Conductor at the start of the stage.
Ends with the room approving the Intent and scope.
Specify
- Led by your experts, who own the content. The Challenger tests it; the Conductor drives the AI. Mob Elaboration begins.
- The AI turns the discussion into requirements or user stories (one or the other, as your organisation works), and the business reviews them in the room.
- Critical rules are captured as decision tables: inputs and outcomes an expert can check without reading code. The AI drafts them.
- Each part of the application gets a risk tier, recorded in the risk tier register. The AI proposes the tiers (Practices, chapter 1).
- The data architecture level is chosen (Practices, chapter 1) and the non-functional requirements agreed (Practices, chapter 2).
Your documents: process descriptions, policies and business rules, existing requirements, example reports and forms, and your non-functional requirement standards, given to the AI by the Conductor as the Challenger selects them. Your experts bring examples into the room.
Ends with gate G1.
Design
- Led by the Conductor, with the Roadie on environments and security.
- Architecture, components and screen mockups.
- The AI proposes the Units of Work, the Bolts and the build order, and the room approves them.
- Before any unit is planned, the build-readiness spreadsheet sorts each requirement by what it depends on (Practices, chapter 4).
Your documents: architecture and integration standards, the security constraints package, interface specifications for connected systems, existing data models, and brand and interface guidelines, given by the Conductor, with the Roadie for technical material.
Ends with gate G2.
Build
- Led by the Conductor; your experts decide what appears on screen. Mob Construction, Bolt by Bolt.
- Each Unit of Work is built with the controls in Practices, chapter 3: explain-back of critical logic, tests, a small pull request, independent AI review, human review by risk tier, and automated checks.
- Tweaks are made on the spot as your experts ask for them; commits are saved at checkpoints so any step can be reversed; one pull request per Unit of Work.
Your documents: for each unit, the decisions, decision tables and mockups that apply, given by the Conductor; the Scorekeeper's feedback record and the session transcripts whenever the AI needs to clarify something.
Ends with gate G3 for each unit.
Prove
- Led by your business owner and technical owner.
- Your experts decide on any features nobody asked for, before user acceptance testing.
- Acceptance tests and user acceptance testing.
- The traceability matrix: every requirement to what was built and its tests, and everything built back to a requirement.
- The evidence pack is assembled and signed.
Your documents: your test standards and change-control evidence requirements, given by the Conductor, so the evidence pack matches what your auditors expect.
Ends with gate G4.
Release and refine
- Led by your technical owner and operations team, under your release and change process.
- The application moves through Test and UAT to production, with safety nets in place.
- The Information Model is produced for your architects, and the Data Model for your database administrators, developers and support teams (Practices, chapter 1).
- One or two of your experts refine the build, and feedback loops back to Frame for the next change.
Your documents: your release, change and operational handover requirements, given by the Conductor or the Roadie.
Ends with the release approved under your change process.
Days, not weeks. S1 to S4 happen in the Blitz: two to four days, everyone in one room. The stages give the work its order; they are not weeks on a plan.
The four gates (formal sign-offs)
Every stage ends with a person choosing to approve the work or ask for changes. The AI build tool can't skip that step. Four of these checkpoints are gates: formal sign-offs with named approvers.
Spec agreed
After Specify, given by the business in the room. It passes when the requirements or user stories have been reviewed and approved there and then, not sent away for later comment.
Ready to build
After Design, given by the Conductor and your business owner. It passes when the build-readiness spreadsheet, the risk tier register and the data architecture level are done.
Unit accepted
For each unit in Build, given by a named reviewer chosen by risk tier. It passes when the tests pass, the AI review's findings are resolved, human review is done for that tier, and the unit's feature inventory has been checked, so that nothing unrequested is left undecided.
Go-live
After Prove, given by your business owner and technical owner together. It passes when the evidence pack is signed.
The sign-off register
Every approval is recorded in one sign-off register, a plain table kept with the project. It holds the four formal sign-offs and, marked separately, the AI build tool's own stage approvals, which are not the same as your stakeholders signing off. Every expected sign-off is listed during preparation as pending, and filled in as the work happens. Any timeline or dashboard is simply a view of this register. The register itself is the record. A blank register comes with the sign-off timeline below, a free download from theinstantframework.com.
| Each entry records | What it holds |
|---|---|
| Sign-off | G1, G2, G3 (with the unit), G4, or a stage approval by the AI build tool |
| Stage and session | Where it falls, and which session if the Blitz is split |
| What was signed | Its name, version and a link: the requirements, the design, a unit's code, the evidence pack |
| Signed by | The name and role of each person who signed |
| Decision | Approved, approved with conditions, changes requested, or pending |
| Conditions | Any conditions or exceptions, each with an owner and an end date |
| Date | When it was given, or when a pending one is due |
| Recorded by | Who entered it |
| Official record | A link to your own approval or change system, where that is the official record |
The Instant sign-off timeline
The sign-off register can be shown as a visual timeline: the stages from Prepare to Release, the sessions of a split Blitz, and each sign-off with the names of the people who gave it, when, and on what conditions. Sign-offs still waiting, or overdue, stand out. It can be brought up on screen at any point in the Instant process, so the room, your steering committee or an auditor can see at a glance where things stand and who stands behind each step. It prints to PDF for the evidence pack.
The timeline is free under the Apache License 2.0: you can use it, change it and share it, including commercially, as long as the Falcra notice stays in the file and any changes are marked. It is a single file that opens in any web browser: nothing to install, no account, and it works offline, so your sign-off data never leaves your own computer. It is a free download from theinstantframework.com.
Mapping to the current engine, AWS's AI-DLC
Instant currently runs on AWS's open-source AI-DLC (chapter 10). This is a mapping, not part of Instant's definition. In AI-DLC, Frame runs in its Ideation phase, Specify and Design in Inception (Mob Elaboration), Build in Construction (Mob Construction), and Release in Operation. Prepare and Prove are Instant's own. Each Instant stage is a group of AI-DLC's stages with matching boundaries. Another engine would get its own mapping, and the stages would not change.
What gets produced
Everything an engagement produces is kept as plain files in the project, readable without the AI build tool. That is what makes the work auditable and what lets you take it away.
| Artifact | Stage | Owner |
|---|---|---|
| Brief; readiness checklist; security constraints package | S0 | Challenger and your security lead |
| Session transcripts; feedback record | S1–S4 | Scorekeeper |
| Intent (the goal) and scope | S1 | The room |
| Requirements or user stories; decision tables; risk tier register; data architecture decision | S2 | Your experts |
| Design and decisions; mockups; Units of Work and order; build-readiness spreadsheet | S3 | Conductor |
| Code; pull requests with intent summaries; explanations of critical logic; AI review reports; check results | S4 | Conductor |
| Acceptance tests and results; traceability matrix; evidence pack | S5 | Business and technical owners |
| Release record; monitoring and audit set-up | S6 | You |
| Information Model, for your architects; Data Model, data dictionary and schema export, for your database and support teams | S6 | Conductor; reviewed by your technical owner |
| Sign-off register | S0–S6 | Stage Manager, or the Conductor if there is none |
What you commit
Instant works because the right people are in the room. This chapter sets out what the method asks of your organisation.
What the method asks of you
Instant asks a lot of the organisation for a short time. Each of these is something the method depends on.
People
Every stakeholder, without exception, in one room for every Blitz session they are needed in. This is the hardest principle to meet, and the one Instant depends on most. In a split Blitz, the same people come back for each session, with no stand-ins.
Time
Preparation. Then either two to four consecutive Blitz days cleared of other meetings (people can work on their own tasks in the room while the AI works), or, for a split Blitz, every session booked in advance with gaps of a week at most. Then one or two experts afterwards.
Decisions
People in the room who can approve requirements, designs and trade-offs on the spot.
Environments
Development, Test and UAT, and Production, as in any lifecycle (Practices, chapter 2).
Recording
Every Blitz and expert session is recorded in Teams and transcribed, always. Everyone taking part agrees to this during preparation, and you approve it. The transcripts are cross-checked against the Scorekeeper's feedback record and given to the AI build tool when needed. They are your data, handled under your policies.
Signatories
A named business owner and a named technical owner for the evidence pack.
The engine today
Instant currently runs on AWS's open-source AI-DLC. AI-DLC is the build engine. Everything you receive, including the application, has no dependency on it.
Three things work together in an Instant engagement.
Instant
The people, stages, sign-offs and documents described in this guide.
AI-DLC
An open-source workflow, published by AWS, that walks an AI through the stages of building software and pauses for a person's approval at each one.
Claude Code and Claude
The tool that does the work and the AI model behind it. The model can run through your own cloud account.
AI-DLC can be used commercially. AWS keeps adding features to it, so any engagement needs a way to adopt new releases safely.
Only the build engine is AI-DLC. The finished application, and the evidence behind it, have no dependency on AI-DLC or AWS.
Glossary
- Acceptance test
- A test, written by your experts or testers, that states what the software must do.
- AI-assisted development
- Developers using an AI coding assistant to write code faster, inside the usual lifecycle. Not the same as AI-driven development.
- AI-Driven Development Lifecycle (AI-DLC)
- A way of building software, defined by AWS, in which the AI drives every stage of the lifecycle and people direct it and decide. Also the name of AWS's open-source workflow that Instant currently runs on. Instant goes hand in hand with it.
- Audit trail
- A permanent log of every change: what changed, the old and new values, who changed it and when.
- Blitz
- The Instant working session: two to four days with every role in one room, consecutive or split into sessions.
- Bolt
- (AWS term) A short build cycle, hours or days, that delivers part of a unit.
- Build-readiness spreadsheet
- A spreadsheet, built before any units are planned, that sorts every requirement by what it depends on.
- Challenger
- The facilitator who questions the room so the loudest voice doesn't win. Often a business analyst, but needn't be, and needn't be technical.
- Conductor
- The technical business analyst who drives the AI build tool while the room watches.
- Data Model
- A document describing how an application's data is stored: tables, columns, keys, indexes, procedures, audit and security, with a data dictionary and schema export. Generated from the database itself, for database administrators, developers and support teams. The companion to the Information Model.
- Decision table
- A business rule written as a table of inputs and outcomes, checkable without reading code. Used to agree critical rules with your experts in Specify, and to test them: each row becomes a test case.
- Directory group
- A group in your organisation's central list of people, used to decide who gets which role in the application.
- Engine
- The AI workflow that walks the AI through the stages and stops at each sign-off. Today, AI-DLC.
- Event Sourcing
- Storing every change as a permanent, ordered event, from which the current record is worked out.
- Evidence pack
- The signed collection of evidence that replaces a waiver at go-live.
- Explain-back
- The AI's plain-English explanation of critical logic, confirmed by an expert.
- Feature inventory
- A plain-English list of everything a user can see or do in a unit, each item traced to its requirement or story.
- Gate (G1 to G4)
- A formal sign-off. The work can't pass it until named people approve.
- Ideation, Inception, Construction, Operation
- (AWS terms) AI-DLC's phases. Instant maps its stages onto them (chapter 8), but they are not part of Instant.
- Information Model
- A document for architects describing the information an application holds: meaning, source, ownership, protection and database mapping, each item with its source. The companion to the Data Model.
- Instant feedback loop
- The cycle in which the AI builds, the room reacts to working software and decides, and the AI builds again.
- Intent
- (AWS term) The business goal everything built traces back to.
- Mob
- The Instant method: every role working together with the AI, in one room.
- Mob Elaboration, Mob Construction
- (AWS terms) The room working out the requirements and design, then building, with the AI in real time.
- Non-functional requirement
- A statement of how well the software must work, such as how fast, reliable, safe and accessible it must be.
- Pull request
- A proposed change to the code, reviewed before it's accepted.
- Risk tier
- The importance of a part of the application: Critical, Important or Standard.
- Risk tier register
- The record of the risk tier of each part of the application, with the reason, who decided and when.
- Roadie
- The developer on call who sets up environments, handles security requirements and fixes build problems.
- Scorekeeper
- The note-taker who records your experts' feedback.
- Sign-off register
- The single record of every approval: who signed what, when, and with what conditions. Any timeline is a view of it.
- Single sign-on
- Signing in to the application with the work account you already use.
- Stage (S0 to S6)
- One of the seven stages of an engagement, from Prepare to Release.
- Stage Manager
- The optional role that clears the path to production.
- Traceability matrix
- A table linking each requirement to what was built and the tests that prove it, and everything built back to its requirement.
- Tweak
- A small cosmetic change asked for in the room, accepted on screen, with no story or pull request of its own. A tweak that changes behaviour is a rule, not a Tweak.
- UAT
- User acceptance testing: the business tries the software as if for real and signs it off.
- Unit of Work
- (AWS term) A self-contained piece of the application, built and reviewed as one.
- Unrequested features list
- Anything built that traces to no requirement, for your experts to keep, change or remove.