Instant Practices

Requirements or user stories

The AI build tool offers two ways of capturing what the software must do: requirements, or user stories. Generally only one is needed, so only one is used. Which one suits you depends on how your organisation already works. Either way, the business reviews the result in the room (sign-off G1).

Risk tiers

Not every part of an application matters equally. A mistake on a help screen is an inconvenience. A mistake in a payment calculation can be a loss, a fine or a safety event. Instant asks the room to sort every part of the application into one of three tiers, and to record who decided and when.

Recording and managing tiers

Tiers are kept in the risk tier register: one row for each part of the application, with its tier, the reason, who decided and when. The AI build tool proposes the parts and a suggested tier for each, so the room starts from a list, not a blank page. Your experts and business owner confirm or change each one, the Challenger tests the reasons, and the Conductor keeps the register. No row may be left undecided at gate G2. When scope changes, rows are added or re-tiered, and each change is logged beside the original decision. The register goes into the evidence pack.

A ready-made register (a spreadsheet with the tiers, reasons, change log and a summary) is a free download from theinstantframework.com.

Why it matters. In most applications only a few parts are Critical: a handful of rules and calculations. Line-by-line human review is concentrated there, while automated checks and AI review cover the rest (chapter 3). That is how review keeps pace with AI-written code without lowering the bar where it counts.

Data architecture: how much change history to keep

This choice is about the record of changes to your data: who changed what, when, and what it was before. It is not about the business data itself, which is stored in full at every level. If the application holds transactions, cases or readings, those are kept whichever level you choose.

The level is chosen in Specify, before design, because it shapes the database design and is costly to change later. Instant's data architecture rule tells the AI build tool to stop before design until a level is recorded, and gate G2 can't be passed without it. The crew advises; your business owner decides.

An example: a manager raises an approval limit from $5,000 to $10,000.

Level 3 has a cost: more design up front, a specialist pattern your own team must be able to maintain, and changes that take a moment to appear on screen. Nothing is deleted at Level 3, so where privacy law requires personal data to be removed, the design handles it explicitly.

Recording who viewed what, as opposed to who changed it, is access logging. It is a separate decision, often required for personal or sensitive data, and can be added at any level.

Six questions to choose the level

1. Will a regulator, auditor or court ever ask why something was decided, or what was known at a past date?
2. Do the rules that drive decisions change over time, and must old decisions stay explainable under the old rules?
3. Will several people change the same records at the same time?
4. Must the change history of a record be visible in the application itself?
5. Who will maintain the application after handover, and have they worked with Event Sourcing before?
6. Is there personal data that may have to be deleted on request?

A yes to question 1, 2 or 4 points toward Level 3. A no to all of questions 1 to 4 points to Level 1 or 2. Question 5 weighs against Level 3 if the people who will maintain it have no experience with it. The crew shows the room what the answers point to, and your business owner decides. The level, the answers, who decided and the date are recorded. If the level changes later, the change is recorded alongside the original decision, not instead of it.

The security constraints package

Some organisations have security rules the build must never break. If you want that, your security lead writes them down as a short set of plain files before the Blitz. Examples: the application must not be reachable from the internet, people must sign in through your identity provider, only approved protocols may be used.

The AI build tool is given the package and builds within it throughout. If someone in the room asks for something that would break a constraint, the build stops and says it can't proceed. It does not look for a way around. A halt isn't overridden in the room. Only your security lead can change the package.

The AI build tool has its own generic security defaults. They are standard industry practice, not your policy. The package is how your actual policy gets into the build.

Jira

If your organisation uses Jira, the AI build tool can create cards there during the engagement, through a Jira connector. The cards are created on the Stage Manager's instruction, or the Conductor's where there is no Stage Manager. The starting point is the Instant Jira backlog: 15 epics and 130 tasks covering everything from the first conversation to handover, including the approvals, security, environments and production readiness that usually stall a project. Each task carries its stage, an owner role, and whether it is always needed or only in some situations, and long-lead tasks are flagged to start during preparation. It imports straight into Jira. It is free under the Creative Commons Attribution 4.0 licence (CC BY 4.0): you can adapt it and share your version, as long as you credit Falcra. It is a free download from theinstantframework.com.

Information Model and Data Model

When the application is built, the AI produces an Information Model for your architects: what information the application holds, what each item means, where it comes from, who owns it, how it is protected, how long it is kept and how it maps to the database, with diagrams. Every definition says where it came from: an approved requirement, the code, the running application, or an assumption still to be confirmed. Nothing is filled in from what applications like this usually contain, and gaps are listed with the role that should answer them. The AI reads the requirements, decisions and code and changes nothing. If you supply your enterprise information model or glossary, it maps to that. The skill and template work with any application, are free under the Creative Commons Attribution 4.0 licence (CC BY 4.0), and are a free download from theinstantframework.com.

Alongside it, the AI produces a Data Model for your database administrators, developers and support teams: how the information is stored. It covers every table, column, key, constraint and index, any views, procedures and triggers, how the chosen level of change history is implemented, database security, and the migration history, with diagrams, a data dictionary for your catalogue tools, and a schema export. It is generated from a non-production copy of the database itself, ideally through a direct read-only connection (chapter 2), so it is accurate on the day it is produced, and it is regenerated at every release. Where you supply database design standards, it lists any departures; without them, it describes and doesn't judge.

The two are kept apart because they answer different questions for different people: what the information means and who owns it, for architects; and how it is built, for the people who run it. Produced together, they reconcile: every entity maps to its tables, and every business table to an entity. The Data Model skill and template are also a free download from theinstantframework.com.

Alongside the build, not after it. These controls run as each unit is built during the Blitz. Most are automated or done by the AI; people spend their attention where the risk tier says it matters.

AI-DLC closes the gap between the business and the software. It also opens two new gaps. Both come down to the same shift, and this chapter explains both and the controls that answer them.

Problem 1: nobody wrote it, so nobody fully understands it

A developer who writes code understands it: why each rule is there, what they assumed, and where the risky parts are. With an AI build tool, the code arrives complete. On a business application it can run to hundreds of thousands of lines. Anyone can read it, but understanding it well enough to vouch for it takes nearly as long as writing it.

In a business-critical application, a wrong rule can mean lost revenue, a regulatory fine or a safety incident. Someone has to be able to say "this does what the business needs", and be accountable for it.

AI-written code has four features that make this harder.

The wrong answer: a waiver

A common response is to ask the business to sign that it accepts that AI wrote the code. That moves the risk onto people who have no way to judge it. It is a disclaimer, not an assurance. A regulator or a court will ask what checks were done, not whether someone signed a waiver.

The right comparison: how organisations already cope

Organisations already run a great deal of code that nobody inside them understands: old systems whose authors have left, open-source libraries, vendor software. They never gained confidence by reading every line. They gained it from specifications, testing, review of the risky parts, monitoring and clear accountability.

Financial auditors work the same way. They don't check every transaction. They test the controls and sample by risk. AI-written code needs the same discipline, applied deliberately.

Problem 2: peer review breaks at AI volume

Traditionally a developer raises a handful of changes, and a colleague reviews each one before it is accepted. With AI, every instruction can produce a change, so hundreds can arrive, some of them tens of thousands of lines long. They are hard to understand, let alone approve. At that volume, "a person approved it" becomes a formality that proves nothing.

Peer review can't simply be dropped, because it does four jobs.

In regulated organisations, that two-person rule is often a formal change-control and audit requirement. Removing review would fail audits. The answer is to keep all four purposes and change what the second person reviews, and how much of it.

The eleven controls

Each control says what it is, who does it, when, and what evidence it leaves behind. Together, the evidence forms the evidence pack that your business signs off (control 11).

Working in Git: Bolts, Tweaks and pull requests

An AI build produces changes at a pace no review process was designed for. If hundreds of small requests a day each became a commit, a pull request and a story, the reviewers and the board would be buried. Instant separates four things that are usually treated as one.

Tweak or Bolt? A Bolt builds something: a short build cycle that delivers part of a unit. A Tweak adjusts how something already built looks or reads. The test is simple: a Tweak that changes behaviour isn't a Tweak. If a small request changes what data is shown, who can do what, a calculation, a status change or an automatic action, it's a rule. It's recorded as a decision and handled like a requirement, with its own line in the pull request and the full review its risk tier needs. Moving a button is a Tweak. Making the button appear only for managers is a rule. The AI build tool classifies every small request, and says so when a Tweak is really a rule (chapter 4).

Defaults, where you don't have your own:

• Branches. One short-lived branch per Unit of Work, named with its ticket key, so every commit links to the unit automatically, Tweaks included. That satisfies a "every commit references a ticket" rule without anyone writing stories for Tweaks. The branch is merged through a pull request, then deleted.
• Merging. Squash on merge, so the main branch has one commit per Unit of Work. The detailed commits stay in the pull request's history for rollback and audit.
• Branch protection, switched on once by the Roadie: no direct changes to the main branch; automated checks must pass; a named person must approve, and neither the AI nor the Conductor who raised the change can approve it; and every comment thread must be resolved.
• The pull request template. One file in the repository, picked up by every major Git host. The AI fills it in and the Conductor checks it before review. It is a free download from theinstantframework.com.

Your conventions win. If you already have a branching model, merge rules or ticket-linking rules, Instant uses them. It needs only one pull request per Unit of Work, and nothing reaching the main branch any other way.

Questions on a pull request

The AI build tool runs in one session, on one machine: the Conductor's. Only that session holds the build's context, so every reviewer's question goes back through the Conductor, the same way every time.

• Ask on the pull request. The reviewer writes the question as a comment on the line it concerns, starting with "QUESTION:", one question per comment. Questions and answers stay on the pull request, not in email or chat, so the record sits with the code.
• The Conductor sorts it into one of three kinds, because each kind goes to a different place.
• How the code works: the Conductor puts the question to the AI build tool on the build machine, as a question only. The AI answers and changes nothing (chapter 4). Its answer says how it knows (seen it working, read it in the code, or assumed), and the Conductor checks it before posting it under the comment.
• Why it was built this way: the Conductor answers from the record of the room: the Scorekeeper's notes, the transcripts and the sign-off register.
• Whether it should do this at all: this is a business question. The Scorekeeper puts it to the expert who owns it, and the answer is recorded. Neither the AI nor the reviewer decides it.
• Any change goes in as a new commit on the same pull request, and the reply links to it. The reviewer closes the question once satisfied.
• No merge while a question is open. The Roadie switches on the Git host's setting that blocks merging until every comment thread is resolved, so this is enforced, not left to habit.
• Questions are run at set times: during the Blitz, at the end of each Bolt, so the room isn't interrupted; after the Blitz, at least once a day at an agreed time.

An answer from the AI is a claim, not proof. Anything that matters is confirmed by a test.

How much human review each tier gets

When each control applies

Features nobody asked for

An AI often builds whole features nobody asked for: an extra screen, an export button, a dashboard, a notification, a setting. More often than not they are right, but often they aren't. They tend to surface only in testing, or in front of stakeholders during a demonstration, when someone stumbles on something nobody knew was there. A person who isn't a business expert can't tell what it is, let alone whether it belongs or is correct.

It happens because the AI is built to be helpful and complete. Where the stories leave a gap, it fills it with what similar applications usually have. It works fast and in volume, and nobody reads every line, so additions go unseen. Traceability usually runs one way only, from each requirement to what was built. Nothing checks the reverse, so a feature with no requirement behind it has nothing to be traced from.

Why it compounds

One unrequested feature is a nuisance. An AI build can add tens of them across an application, each plausible on its own. And they don't stay separate. Each unrequested feature comes with rules the AI assumed, and later features get built on top of those rules, so they end up tied to one another. Removing or changing one can quietly break another.

Finding them afterwards is slow. The AI can list what it built by reading the code, but it can't tell you why a rule exists or whether it is right. Those were assumptions, never recorded, and only your experts can judge them. Without a record, each feature has to be traced and tested one at a time, and across tens of interlocked features that takes far longer than building them did. Real examples, with screenshots, are at the end of this chapter.

That is why additions have to be governed as they are made, not discovered later: build only what was asked, and list everything a unit contains the moment it is built, while it is still one feature and not a web of them.

How Instant deals with it

If it has already happened

Where an application has already been built with additions nobody asked for, testing every feature by hand is the slowest way out. Reading the code is much faster than clicking through every scenario, so recovery starts there.

Triage, don't review

An AI can produce more features in an hour than a room of experts can review in a week. If every addition has to be read and decided one by one, the bottleneck simply moves from building to reviewing, and the project is back to the old, slower pace. So Instant doesn't ask your experts to review everything. The AI sorts, and people make only the decisions that need them. It is the same principle as code review: evidence, not reading. It applies both to the feature inventory checked at each sign-off G3, and to recovering an application that has already been built.

How to do it in practice

The policy is a starting point. Your organisation can tighten it, for example by making every change in a regulated area an expert decision.

Most of it is rules

The hardest additions to spot are not new screens. They are rules: a drop-down nobody asked for, filled with data that looks familiar, that appears only in certain circumstances. Nobody knows when it appears, where its contents come from, or why. A drop-down looks cosmetic, but the rule behind it is behaviour, and it needs deciding and testing like any other.

So the inventory lists the rules, not just the controls. The AI writes each one as a single plain sentence: when this condition holds, this appears, changes or is filled with these values, from this source. For example: "When a request is overdue and nobody is assigned, it appears in the unassigned list, oldest first."

Every rule also says where its data really comes from: a real source that has been checked, a value worked out from other data, a fixed list written into the code, or sample data. Familiar-looking values from a fixed list or sample data are the ones most likely to mislead.

From decision table to test

Rules need testing, but testing them by clicking through every screen is what makes this slow. Instead, each row of a rule's decision table becomes a test case: this condition, this expected result. Your experts check the table, which takes minutes. The AI turns the rows into automated tests, which run on every change. A person watches a sample of them run on screen. Rows nobody can fill in, because nobody knows what should happen, are exactly the questions for your experts.

What to ask the AI

Produce the feature inventory grouped by business flow, and list the rules, not just the controls: for every field, button, list and drop-down, when it appears, what fills it and from where, and what changes it. For each item, give what it does, the requirement or story it traces to (or "nobody asked"), how you know (seen working, read from the code, or assumed), its category under the triage policy, and what depends on it. For each rule, say where its data really comes from: a checked source, a calculation, a fixed list in the code, or sample data. Write each flow's rules as a decision table, turn each row into a test case, and list load-bearing items first.

Inside an Instant build, this happens unit by unit at sign-off G3, so experts see a handful of items at a time while they are fresh. The pile of hundreds only builds up when that step is skipped.

Real examples, and how Instant handles them

These screenshots come from a real AI build, using sample data. Each shows a different way an AI build drifts when nobody is governing it, and the Instant guardrail that answers it.

Traditional and Instant, side by side