Written for someone who reads the whole thing — a domain expert, or an AI asked to find what is wrong with it. Nothing here is withheld to create curiosity. What is missing is missing because it is not proven yet, and it is named as such.
NCT is an engineering control system. It sits underneath AI-assisted development and keeps one question answerable at all times: what is actually true about this project right now. Not what the AI reported. Not what the plan said. What is true, with evidence that outlives the session that produced it.
This is the specific, reproducible sequence the system was built against:
The code is correct. The tests are green. The report is complete. All three are perfectly consistent with each other, and all three have drifted from the request. This is not a model being weak. It is what a probabilistic system does. A stronger model drifts more convincingly.
Ashby's Law of Requisite Variety: for one system to control another, the variety of the controller must cover the variety of what it controls. Two probabilistic systems checking each other raises the probability of catching an error. It does not change the structure — there is still no deterministic reference to compare against.
The stronger the model, the less the layer underneath is allowed to be weak.
A stronger model proposes more complex work, touches more surface, and sounds more credible doing it. Observability, constraint, authority and recovery have to rise with it, or the control relationship breaks. This is the load-bearing argument of the entire product. If it is wrong, the product is wrong.
Each line below is a place where most systems collapse two different things into one field. Every collapse is a place where, afterwards, nobody can prove which one it was.
Three separate columns, because merging them is exactly the failure this product exists to prevent.
An unmeasured quantity is not reported as zero anywhere on this site or in the product.
More than a decade as the top IT audit officer — the seat where you always arrive after the fact. The job was to reconstruct what actually happened. Most of the time it could not be reconstructed: not because logs were missing, but because records had been edited by someone with an interest in them, or because nobody wrote anything down at the time. Then AI made the same failure happen in milliseconds, at a hundred times the volume. The product is that seat, turned into a system.
These are the conditions under which the thesis fails. None of them is currently disproven, and an honest reviewer should press on all four.
The single largest gap is named here rather than hidden: there is no engineering team outside the founder running this on real work yet. The backing is real money from a real business, but that business is buying a future system for its own operations — it is not evidence that an engineering organisation will pay for the control layer.
One engineering team that is not the founder's, running real work under it, able to say what it caught.
Three to five concrete cases — where the AI reported completion, every test passed, and the system refused acceptance, and it was later shown that shipping would have caused an incident — would settle more than any amount of additional architecture.