New projects start from November 2026. We are happy to talk now and show you Approval in a short call.
Approval first checks whether the software is already approved for the same use; if it is, that approval and its conditions apply and no new review starts. Otherwise it stores the vendor documents, and a new vendor’s sources and identity are checked first. A model extracts facts with supporting quotes; a quote that is not in the documents is rejected, and a person accepts, corrects or rejects each fact before the model drafts two assessments. The data protection and security officers each review and sign their part; one refusal rejects the request. The request, every document version, every decision and every signature are recorded in a tamper-evident log. When a vendor document changes, the affected fact is invalidated, the approval is out of date and a re-assessment supersedes it; an approval nearing its end is renewed from the current facts.
A department requests software. Approval reads five vendor documents, drafts both assessments and puts them in front of your officers.
ExampleApproval · Request S-112Approval · Request S-117RunningWaiting for a personWaiting for 2 signaturesApprovedRe-check neededRe-assessment S-131Rejected
↩ Document changed → S-131 supersedes S-112↩ Expires in 60 days → renewal
1AIFactsReading and quoting…2 quotes not in the documents14 facts quoted · 1 quote rejected13 facts quoted · 2 quotes rejected1 fact invalidatedS-131: quoting the new version…
2PersonFact reviewAccepts or rejects each factThe quote is real, the reading is wrong14 facts verifiedAll data stays in the EUHosted in the EU, support access from the US
AIDraftsDrafting from verified facts…Security and data-protection drafts
PersonData protection officerReviews and signs2 fields edited · signedSigned “no”, with reasonNotified#1039#1069
PersonSecurity officerNot needed after a “no”Reviews and signsSigned with 1 conditionNotified#1041
Both signed?
4SystemApprovedBoth officers signed. Models cannot sign.Out of date · both officers notified
SystemRejectedOne “no”, with its reasonUS support access · reason on record
S-131
Processing agreement · v1
§ 4.1 “Customer data is hosted in data centres in Frankfurt am Main.” § 4.3 Support staff access the service as listed in annex 2. § 7.2 “Personal data is deleted within 30 days of the end of the contract.”
“Backups are encrypted with keys the customer holds.”not in the document · rejected
“No data leaves the EU.”not in the document · rejected
“Support is provided from within the EU.”not in the document · rejected
3Ledger · hash-chained
#1069Data-protection part signed: no, with reasonprev 0f6a…c3b9→91ce…7d20
#1031Request S-112 filed, scope recorded as a hashprev 4c90…d17e→6c41…e2b9
1Facts extracted for your reviewFive documents, fourteen facts, each with its quote. A quote the document does not contain is rejected.
2Your team decidesThe model proposes and drafts. A person accepts each fact, and only the officers can sign.
3The evidence is recordedThe request, each document version, each decision and each signature is a ledger entry, chained by hash, so none can be changed quietly afterwards.
4It notices when the facts changeA changed document invalidates the facts it no longer supports and reopens the approval based on them.
This shows the process used in Approval, with fictional requests, documents and figures.
The same division of work fits your own processes, as a new application or inside software you already run.
Custom software
We build your application in weeks.
Security, data protection and the review of AI proposals are already built into our template. Coding agents add your process on top of it; automated checks send back whatever breaks its rules, and we review what passes. It runs on your infrastructure, you own the code, and there is no platform subscription.
AI that changes data only after a person approves.
For software you already run: a model prepares a proposal, a person reviews and signs it, and a hash-chained ledger records the decision. Open-source libraries in your own stack.
The agent writes the code. The rules it works under are ours.
Writing code has become cheap. Coding agents are fast, but left to themselves they pick the wrong tools, skip requirements and leave gaps that show only in production. So no agent of ours starts from an empty folder. Every agent uses our template, libraries, instructions and automated checks. We maintain all four.
Every application starts with row-level security on every table, sign-in through your identity provider, AI steps a person approves and a log from which each change can be undone. The agent adds your process to this template.
@octabits-io/*
25 tested libraries
Queues, encryption, data-subject requests, events and the audit log come from our open-source packages, each with its own tests. The agent wires them in instead of writing its own. All of them run on your Postgres, so none adds a sub-processor.
AGENTS.md · skills/
Rules and recipes it reads first
The template gives the agent instructions: how to add a table, how to change one that already holds data, how to add an AI step. Each recipe ends with a command to check the result. Claude Code and Codex read the same files.
pnpm guard
Automated checks after each step
When the agent ends its turn, the guard checks the rules: every table scoped, organisations isolated from each other, migrations safe on tables that hold data, no model call that bypasses the disclosure rules. What fails goes back to the agent. The same checks run before every merge.
Then we review every change
We read every change that passes the checks before merging it. The agent writes most of the code; what goes into your application is decided by people.
Recorded development
Watch an agent use the template
We asked Claude Code, Anthropic’s coding agent, to build a customer management application from a fresh copy of our template. It needed companies, contacts and a company picker. Deleting a company had to preserve its contacts. It chose the data model and worked without intervention for just under nine minutes. The thirty-five-second excerpt is followed by a recording of the finished application.
Claude Code builds customer management on the octabits starter: the task, the skills it reads, the migration, the guard with 9 of 9 checks, its review, a smoke test that fails and one that passes, and its closing message.
The recording shows the resulting application: we add a company, select it for a new contact and find the contact on the company page. Deleting the company preserves the contact. The records are hidden from the other organisation.
What the agent did
Before writing code it read the starter’s skills for adding a table and for changing one that already holds data.
Its migration only adds, so every existing contact stays valid. The guard passed 9 of 9 checks, with no destructive statement.
It noticed that the database link alone would accept another organisation’s company, so the server checks it before saving.
It tried deleting a company on the running app and the contact stayed. Its first attempt at that check failed on a shell error; the cut shows it.
The guard has grown since the Codex run, from 6 checks to 9: it now also replays every migration over tables that already hold rows. The run took 40 turns and cost $2.38, as shown at the end of the recording.
We gave a coding agent, OpenAI’s Codex, a fresh starter and one sentence: invoices, a list, and a button that summarises an invoice with the model we run in-house. It worked unattended for just under nine minutes. The thirty-second excerpt is followed by a recording of the finished application.
Codex builds invoices on the octabits starter: the task, the skills it picks, its question for the in-house model’s address, the guard with 6 of 6 checks, its own tests and its closing message.
The application it built: an invoice is added, the AI suggestion arrives as a proposal, a person applies it and undoes it. The other organisation sees none of it.
What the agent did
It used the starter’s own skills for the table, the AI step, the background job and the review.
It asked for the address of the in-house model instead of reaching for an external provider.
It wrote its own tests: the invoice stays unchanged until a person approves, an applied summary can be undone, and another organisation is locked out.
All 6 automated checks passed, including checks for tenant isolation and model calls that bypass content classification.
No model was connected for this recording. The application used scripted demo responses, as noted by the agent and on the page. Three settings are needed to connect your own model.
How it works
From your process to a running application
01
You describe the process
Tell us how the work gets done, what data and documents you use, and who approves the result. A spreadsheet you use today is a useful starting point. In the first call, we outline how to build your application with our existing libraries.
02
Agents write the code, we review it
Coding agents write most of the code inside our template. Automated checks send back whatever breaks its rules, and we review every change before it is accepted. You can use the first version within a week.
03
You run it on your infrastructure
The application uses your servers, Postgres database and sign-in provider. Your staff review AI proposals, and the log records their approvals. You own the code.
Approval uses the oversight kit to review software requests, as shown in the diagram above. The model drafts assessments with source references. The officers review and sign them, and each decision is logged. We can integrate the same libraries into your existing software.
AI prepares the assessment for your officers to review and sign.
Approval helps regulated organisations assess and approve software. It collects vendor documents, extracts facts with source references and drafts security and data protection assessments. The responsible officers review, edit and sign the documents. Approval runs in your own datacentre on your Postgres database.
Example review: proposed changes with source references, followed by the log entry created when the officer signs.
Draft
Software request 0412
Document management, hosted
Data locationEUEU, FrankfurtProcessing agreement, § 4
Sub-processors23Sub-processor list, row 3
Risk classLowMediumAssessment rule 7
Drafted by the model from verified facts
RejectSign
Signed by the data protection officer
Ledger
#1042Data-protection part signed7c1e…b04a
#1041Draft accepted, 3 fieldse93d…41f2
#104014 facts accepted, 1 edited2a8f…9c17
Pricing
Development at a fixed price, with monthly maintenance.
You own the application code. There are no licence fees or limits on users and workflows. The platform packages will be released under the MIT licence.
Development
Fixed price
per application, in the written proposal
Your application running on your infrastructure and Postgres database
Sign-in with your identity provider, e.g. Microsoft Entra ID
Tests, CI and documentation; the code is yours
A first version within the first week, done in 4–6 weeks
Maintenance
Monthly
a flat fee, no charge per user
Platform package updates and security fixes
Support from the people who built your application
No limit on users or workflows
A separate fixed price for each additional application
For business customers. After a first call you receive a written proposal with scope, duration and price, usually within two working days.
Approval and Reynt use our open-source libraries. We group them into two kits. The build kit handles row-level security, field encryption, data-subject requests, queues, events and telemetry. The oversight kit adds review of AI proposals and records the decisions. The packages run on your existing Postgres database. Each comes with tests and documentation explaining its uses and limits, and all of them will be released as open source under the MIT licence in November 2026.
Put the invariant where it cannot be routed around
Crypto-shredding and blind indexes
Append-only ledger, single writer
Anti-corruption layer
Store-and-forward, backoff with jitter
Boring infrastructure
Programs as values
GitOps and a signed supply chain
Negative documentation
Intent-revealing commits and a work ledger
Encoded procedures
In production
Reynt, our booking platform
We develop and operate Reynt, a booking platform with thirteen packages, four APIs and three frontends. AI coding agents write most of its code. We began publishing individual libraries after using them in production in Reynt.
Automated checks enforce the architecture boundaries, the database enforces key constraints, and integration tests run against a real database in CI. These checks support our review of agent-written code.