Operating system
Speed and control are usually traded against each other. Under supervision you do not get to make that trade. The question a technical due diligence asks is not how fast you ship, it is whether you can show why every change was safe to make.
This is the system now in place at Togethrust, across five repositories. It is also what the fourth movement of an audit, hand over, leaves a founder's team running.
Why it matters
That the findings rest on the code, not on a sample.
That compliance is a control you can point at, not a document you can produce.
That the team can keep it running after the person who built it stops touching it.
The rule
Two repositories state the same rule in their own words, without having agreed it. One says a review that could not run must never look like a review that passed, and makes every path that fails to produce a verdict exit non-zero. The other states it as a standard: a check must have a failure mode distinguishable from its success.
It was learned rather than designed. A pipeline that reported the status of its last command once let a failing test suite report success, and put a broken build on the trunk.
The tool that does the checking was rebuilt so that it cannot report success for a run that failed.
A technical due diligence reader does not ask how many checks you run. They ask what happens when one cannot run.
One example
A hook was wired to record one line each time a background task finished. An audit found eighteen journal files on disk, every one of them empty, spanning a month. The hook had been exiting successfully the whole time.
The note written at the time names the problem exactly: asserting that the hook exits zero is the assertion that failed to fail here.
It was deleted rather than repaired, because nobody had ever read the files and the platform already reported the same counts. The decision was written down and closed with its outcome, rather than removed.
That was not a routine finding. Installing the control layer is what surfaced it, along with several other instruments that had been reporting success while doing nothing.
The chain
A review pass runs over the staged change before a commit is created, and blocks it on any significant finding. A failure to review is treated as a failure, never as a pass.
A single command runs the full suite and reports success only when every check passes. The gates are themselves covered by automated tests, run when they change and again each night, so a control that quietly stops working is caught rather than assumed.
A gate is introduced advisory and promoted to blocking once its findings have earned it. A gate that fires on every commit is one people learn to bypass.
Merging rolls to a pre-production environment automatically. Reaching production is a separate action requiring a named human, and scheduled automation stops at that boundary rather than routing around it.
Auditability
Request and response shapes live in one versioned package that the server and three clients compile against, so a shape change that would break a caller fails to build rather than failing in production.
Assistant contribution is recorded in commit metadata rather than absorbed silently, so it is possible to establish later which changes an assistant touched.
Audit logging has its own storage layer, contract test and integration test against a real database. The store was made redactable once it was established the application could write personal data into it, rather than relying on a measurement of existing rows.
Alerting lives in version control, with thresholds argued from measured outages rather than taken as defaults.
Limits
Every claim above has a boundary. Here they are, so nothing on this page has to be taken on trust.
Most of this landed recently, and deliberately. It is the system now in place, not a track record.
Scanning runs. Scanning does not gate.
The production approval is an enforced pause with a named human on it. It is not separation of duties.
Sensitive fields are classified. Classification is not enforcement, and this page does not claim it is.
One 360° tech audit per quarter. Fifteen hours, fixed scope, a scored report and a 90-day roadmap.
Free diagnostic call first • One company at a time
Tell me about your company →Or write to me at khaled.souf@gmail.com