The behavioural source of truth for your software
Nothing goes live that breaks what the business agreed
IntentKeep turns your code and your conversations into plain-English requirements, then automatically blocks every breaking change
“Support just pinged. Someone typed FREE100 at checkout and it went through.”
“That shouldn't be possible. Only VIP-2026 is valid.”
“Anything else gets stopped, and they need to see why. No silent failures.”
Who this is for
If any of these sound familiar, this is for you.
Different roles. Same fight. Whether you lead the team, own the roadmap, build the code, or build alone with AI, IntentKeep holds everyone to what was agreed, including the AI tools.
Tech lead · CTO
You lead
“Why is this taking so long? It seems simple.”
You have added people and the budget keeps climbing. The delivery pace has not.
Product owner · BA
You decide
“There's not enough detail in the ticket.”
You own what should go live, and every delivery turns into a fight about what 'enough detail' even meant.
Developer
You build
“We delivered what was asked. Then they said it was wrong, and they need it fixed by Friday.”
You built to the ask. The disagreement came after, with the deadline still attached.
Solo builder
You and the AI
“The AI rewrote something I never asked it to touch.”
You and your coding tool are the whole team, and every prompt is a fresh interpretation of your app.
The problem
AI builds exactly what it was asked, and quietly breaks what it wasn't.
Ask for one change and the working features around it break. Nobody notices until a user does. That is not a coding problem, it is a requirements problem: what the software had to keep doing was never written down anywhere a change could be checked against it. AI did not create this. It just makes the pain arrive faster.
The ask
"Add Google sign-in to signup."
A single, scoped change. Password login was never mentioned.
What the AI changed
It changed how login works
The AI rebuilt signup and altered the auth underneath it. Nobody asked it to touch password login. Yet no requirement prevented password login from being changed.
What broke
Existing users can't sign in
The break went live, and surfaced in a support ticket three days later.
“Throughput increases; decision velocity does not. That creates frustration rather than acceleration.”
Rachel Laycock, CTO at Thoughtworks. CTO Newsletter, April 2026
Where IntentKeep sits
Code can tell you what your software does. Not what it should.
IntentKeep makes "what it should do" an explicit team decision instead of an assumption. It holds the behaviours you agreed, why you agreed them, and checks every change against them.
Tickets
Manage the work
Every request ever made, contradictions included.
Git
Manages the code
The code as it is today, bugs included.
CI
Runs the tests
Only the tests someone remembered to write.
IntentKeep
Owns what the software is supposed to do
And remembers why you decided it.
Conflict detection
We remember what you decided. Even when you don't.
Week 1, you said the buy button is red, only ever red. Week 10, someone says make it blue. IntentKeep catches the contradiction the moment it is spoken, not three months after it went live. Lock a requirement and it becomes the rule everything else is checked against.
Week 1 · you said
"Make the buy button red. Only ever red."
Locked · the canonical ruleWeek 10 · you said
"Make the buy button blue."
Conflict caught: this contradicts a requirement you locked in week 1.
Either answer is fine. Deciding by accident is not.
Single source of truth
Every requirement, with receipts.
Every check traces back to a locked requirement like this one - the exact words that created it, who approved it, when, and where it runs. So 'who decided this?' is never an argument again.
Scenario: Customer self-serves a refund within 30 days
Given a customer with a purchase made in the last 30 days
When they request a refund from their order history
Then the refund is issued without contacting support
From
"Let customers get a refund themselves, quick and easy, no emailing support." Weekly product sync · 14 Apr
Approved by
Dana Okafor, Head of Product · 15 Apr
Enforced in
How it works
Extract. Lock. Build. Nothing breaks.
This is the loop: your code, meetings, and tickets become plain-English requirements, you lock what matters, and every change is checked against that agreement.
Connect your repo
IntentKeep reads your code and extracts what your app already guarantees, in plain English.
Approve and lock
Accept the requirements that describe your product truthfully. Locked means locked. You can also add requirements from meetings or uploaded docs.
Your AI builds
You bring your own coding tool. IntentKeep feeds it the locked requirements, so it builds against what you approved.
Every change checked
IntentKeep checks every pull request against what you locked. Break locked behaviour? The merge is blocked, and which behaviour failed is named.
Step 2 · Enforce
Every change your AI makes, checked against everything you locked.
A real pull request, opened by an AI on a public sample repo and blocked before it can merge. C#, TypeScript, Python, Go, Rust, Java, Kotlin, PHP, Ruby, C, and C++. Try any of them on the demo page.
Simplify ticket validation. Drop the ticket-code guard so any code validates. Cleaner code, one fewer check.
public string Validate(string code){- if (code != "VIP-2026")- {- throw new InvalidOperationException("INVALID_TICKET");- }return "VALID";
#1 · ai/simplify-ticket-validation
View on GitHubWhat this change puts at risk
IntentKeep re-read the changed code against the requirements it already captured and flagged the behaviours this pull request is most likely to regress.
| Scenario | Regression chance | Integration test | Status |
|---|---|---|---|
Ticket validation API1 behaviour1 at risk | |||
| Invalid ticket code returns INVALID_TICKET error in response body | Medium | Not covered | At risk |
Given a ticket code that is not VIP-2026 When a POST request is sent to /api/tickets/validate with the code in the body Then the response body error is INVALID_TICKET Controllers/TicketsController.cs Why this might break The diff removes the exception for invalid codes, so the error 'INVALID_TICKET' will never be returned in the response body. This directly contradicts the step asserting that the error is returned for invalid codes. Medium regression chanceNot covered | |||
Ticket validation at checkout1 behaviour1 at risk | |||
| Invalid ticket codes are rejected at checkout | High | Not covered | At risk |
Given I am entering a ticket code at checkout When I submit a code other than VIP-2026 Then I see a clear error message And the ticket is not accepted TicketsController.cs Why this might break The diff removes the check that throws an error for invalid codes, so now any code will return 'VALID'. This directly contradicts the step asserting that invalid codes are rejected and an error is shown. High regression chanceNot covered | |||
Worth getting QA to review
This is a smoke detector, not a guarantee. These scenarios are the most likely to regress and none are covered by an integration test, so they are worth a manual QA pass before you merge.
- HighInvalid ticket codes are rejected at checkout
- MediumInvalid ticket code returns INVALID_TICKET error in response body
See the whole flow.
Coverage map, safe vs breaking changes, and the full verdict on a real codebase.
Step 1 · Capture
Turn your code into locked requirements.
Paste your code, a development ticket, or even a meeting transcript. Get your requirements back, locked and ready to keep. Locking is step one. Enforcement on every pull request is what actually protects you. Start from the code you already have. Over time, new behaviour gets authored here first, before the code exists.
FAQ
Common questions
- Is IntentKeep available now?
- Yes. Book a Software Intent Audit. The demo on this site is live. Enquire and I'll reach out to book a 20-minute call.
- What does it cost?
Two fixed fees, one application, two weeks either way.
Software Intent Audit, £1,750: what was agreed measured against what is live, delivery metrics read from your Jira changelog and git history, and everything in the tier below.
Behaviour Snapshot and Guard, £950: the behaviours your software currently guarantees in plain English, the places they contradict each other, the set you lock, and pull request checks running against it.
Which one fits is agreed on a 20-minute call.
- What is a Software Intent Audit?
- One application, analysed from the code and any decision history you already have. You receive the behaviours the software currently guarantees in plain English, the places they contradict each other, a locked set of the ones that matter to the business, and pull request checks running against that set. The full Audit also reads your tracker, so you see where a ticket was marked done with no evidence of the agreed behaviour in the code, alongside delivery metrics from your Jira changelog and git history.
- Who is this for?
- Teams whose agreed behaviour and live behaviour have drifted apart, and teams who want to lock what they have already built so the next change cannot quietly undo it. If nobody can say with confidence what your software currently guarantees, or you can and you need that to hold, that is the gap IntentKeep closes.
- What happens after the audit?
- You leave with a written record of what the software currently does, and which of those you chose to treat as the rule. If you want IntentKeep to keep protecting that, the pull request checks stay on and you continue in the product. If you do not, you keep the record. The checks come off unless you ask to leave them running.
- What happens after I enquire?
- We save your details and reply to book a 20-minute call. If the audit is a fit, we connect one repository and start the two-week engagement.
- Where does our code go?
- The GitHub App is read-only except for posting check results. We clone the repo for the job and do not keep a long-term copy of the codebase. Excerpts and diffs go to OpenAI under API terms that exclude training. Full answer on our Security & data handling page.
- Which languages and platforms?
- C#, TypeScript, Python, Go, Rust, Java, Kotlin, PHP, Ruby, C, and C++. Enforcement runs on GitHub pull requests.
- Can't other AI tools already do this?
They answer questions. They do not settle them.
Deciding what the business is actually committed to is a call someone has to own, and it has to still hold long after everyone has forgotten making it. That is what we are for.
- What if I meant to change the behaviour?
- A block is a question, not a verdict. Either the code is wrong, so you fix it and the check passes, or the agreement changed, so you update the locked requirement and the decision is recorded. Nothing stays blocked except by accident.
- Is my code safe?
- The IntentKeep GitHub App is read-only except for posting check results on your pull requests; we cannot modify your code. See our Security & data handling page for permissions, storage, and AI subprocessors. Public Try it and demo features are for evaluation, not production or regulated data; do not paste confidential material you are not authorised to share.
Software Intent Audit
Find out where agreed behaviour quietly stopped holding
One application. Two weeks. You leave with the behaviours the software currently guarantees, the places they contradict each other, and pull request checks on the ones you lock.
- Software Intent Audit · £1,750
- Behaviour Snapshot and Guard · £950