Auditable from day one is a different product, not a later feature
Most platforms add an audit trail when a customer asks for one. By then the shape of the data has already decided what can be proven.
A detective control finds the payment that should not have happened. A preventive control means it did not.
Control frameworks distinguish preventive controls from detective ones. In home-improvement lending the distinction is unusually concrete, because the gap between them is a payment that has already left the building.
A detective control is a report. It runs nightly, or weekly, and it tells you that a draw was funded without the homeowner's sign-off. You now have a remediation problem, a customer with a grievance, and a finding to explain. Everyone involved did their job — the report worked exactly as designed.
A preventive control is a refusal. The draw could not be funded, because the authorization did not exist. There is no remediation, because there is nothing to remediate.
Not through carelessness. It is that a refusal has to live somewhere that every path passes through, and in most systems there is no such place. Validation sits in the handler for the endpoint someone happened to be building. The next endpoint gets its own copy, or does not. The nightly job that imports a partner file has neither.
So the check gets moved to where it can see everything — a report over the data after the fact. That is a rational engineering decision that produces a fundamentally weaker control.
The only place every path genuinely converges is the data store. A constraint there is not a check that each caller must remember; it is a fact about what the database will accept. It covers the endpoint written next year and the migration script written under pressure at 2am.
An application check answers "did we remember, here?" — and that question accumulates with every endpoint you add. A constraint in the data answers "is this possible at all?", once.
This has a cost worth naming: constraints in the data are harder to change than code, and they will occasionally refuse something a person believes should be allowed. That friction is the control working. A safeguard nobody ever bumps into is usually a safeguard that is not doing anything.
Ask what happens if you try to do the forbidden thing. If the answer involves a dashboard, an alert, or a queue, it is detective. If the answer is that the operation fails, ask where the failure is enforced — and ask them to demonstrate it rather than describe it.
A control you can describe is not the same as a control you can demonstrate. Ask a vendor to attempt the thing their platform forbids, in front of you.
Pick a closed project. We will show you the document you would hand a regulator. If it does not answer the question, nothing else matters.