About
The software prepares. A qualified person decides.
This page is short because there is not much to say that is both interesting and true yet. What the product is, who it is for, the one principle it is built on, and exactly how far along it is — which today is a controlled pilot, before general availability.
What it is
One record for every company a practice is answerable for.
Compliance Cockpit is a web application for UK accounting practices. It holds your client companies, their statutory registers and the history behind them, their deadlines, the corporate actions that change them and the documents that evidence them — in one record, rather than a shared drive, a spreadsheet and a row of open Companies House tabs.
Who it is for
The firm that carries the responsibility. A sole practitioner with thirty companies, and a twenty-person firm that needs a conflict wall between its own staff, are both the audience — which is why visibility between colleagues is configurable and tenancy between practices is not.
Practice roles run owner, admin, manager and staff. A client-portal login is a separate role that no member of staff can be given, and it carries none of the practice permissions.
Who it is not for
A company running its own compliance without an adviser. The design assumes a qualified person at the other end of every judgement the software declines to make — the articles it does not hold, the accounts it cannot test, the meeting it was not present at. That assumption only holds when such a person exists.
The principle
It prepares and recommends. It never decides.
Compliance Cockpit prepares a Companies House filing and stops: the form, the data, the statutory deadline, the supporting documents and a sealed, content-hashed package — which a person at your practice then submits. That is not a setting somebody could switch. The filing client throws and opens no socket, so there is no code path in this build that could behave otherwise.
The same boundary runs through the rest of it. One add-only engine writes to a live statutory register, after a reconciliation check and a confirmation showing exactly what will be written. Errors block and warnings do not. Where the public filings contradict each other, the workflow stops instead of picking a number. Everything generated is a draft for a qualified person to complete, check and sign, and it says so on its own face.
That boundary is not a limitation we are apologising for. It is the reason the output is defensible when a client, an auditor or a court asks where a figure came from.
How it is built
We read the Companies Act rather than guessing at it.
The statutory content is written from the sections, and the section is cited in the product at the point the rule applies. An SH01 is due within one month under s.555 — and one month from 31 January is 28 February, not 2 March. An AD01 has no deadline at all, because under s.87(2) the change takes effect on registration. A sub-division needs an ordinary resolution of the members under s.618(3), so a pack of board minutes alone is named as a gap rather than passed off as authority.
A practitioner read every sentence the product generates
Before this pilot, a reviewer went through the generated output as a UK company secretary and corporate lawyer would: board and general meeting minutes, written resolutions, the filed resolution copy, pack assembly and omissions, statutory thresholds and majorities, stamp duty arithmetic, filing deadlines and their citations, the validator prose shown immediately before approval, and the client-portal approval wording.
It was not flattering. Minutes recorded a meeting nobody knew had taken place, with an attendance list taken from the register of directors. A share transfer certified compliance with articles the system does not hold. Distributable profits were confirmed because somebody had used a dropdown. Each finding is written up with what it would have done — to a director asked to sign, to the practice that produced it, and in litigation.
The findings were published, not buried
The review lives at docs/legal/legal-professional-review.md in the repository, findings first, severity by severity. It also lists what it checked and found correct, because a review that records only faults misrepresents the thing it reviewed.
Where the wording could be fixed, it was, and every change is pinned by a regression test that was proved non-vacuous by reverting the fix. Where it could not — because the data to support the sentence does not exist — the certainty was replaced by a stated assumption or a bracketed gap, and the underlying product change is listed as still open.
24
findings, published in full
Three critical, six high, seven medium and eight low — each with its statutory basis.
7
items still open, listed one by one
Each is a product change rather than a wording change, so none could be closed by editing a sentence.
0
code paths that can file
The Companies House filing client throws and performs zero network I/O.
The rule that came out of that review now governs the product: where a legal fact cannot be proved from the records held, the document does not assert it. It prints a bracketed instruction to complete the point before signing, and says why the system could not — it does not hold the articles, it does not hold the accounts, it was not at the meeting.
Where we are
Pre-general-availability, in controlled pilot.
This is pre-1.0 software, and we are not going to describe it as anything else. The pilot is deliberately narrow, and the reasons are published rather than paraphrased.
- The pilot environment holds synthetic data, and pilot firms are asked not to upload real client documents.
- Only the currently deployed pilot commit is supported, and it carries no security-update guarantee.
- Self-service signup is off. Accounts arrive by invitation, and client-portal logins are provisioned by an operator.
- The technical due diligence run before this pilot would deploy the product internally today and would onboard unpaid pilot firms told plainly what is missing. Asked whether to onboard paying firms, or to recommend general availability, it answers no to both — with named reasons, which is why the pilot is shaped the way it is.
Still to complete
The facts this page cannot yet state.
The document generator has one rule it will not break: where a fact cannot be supported by the records held, it does not assert it — it prints a bracketed instruction to complete the point before signing. It would be a poor advertisement for that rule if this page quietly broke it, so the details below are shown as the gaps they are.
The registered name and company number
[TO BE COMPLETED BEFORE LAUNCH — the registered name and company number, exactly as on the register]
The registered office
[TO BE COMPLETED BEFORE LAUNCH — the registered office address]
The people, and in what capacity
[TO BE COMPLETED BEFORE LAUNCH — the named individuals behind the product, and their roles]
How to reach us
[TO BE COMPLETED BEFORE LAUNCH — the address for pilot enquiries and for responsible disclosure]
Each of these is a fact about the business rather than about the software, and each will be filled in from the record when it exists. None of them will be filled with a plausible sentence in the meantime.