A gate that reads a field the same statement can set is not a gate
Most controls in most systems are conventions with a validation message attached.
Ask how a platform prevents funding against an unperfected lien and you usually get a description of a workflow. There is a step, the step has a checkbox, the checkbox is required. Somebody sets a field, and later something checks the field.
That is not a control. It is a convention, and the failure mode is not malice — it is a support engineer clearing a stuck record, a migration that back-fills a default, a bulk import that sets everything to the value that makes the import succeed. The check passes because the thing it reads was written by the same process it was meant to constrain.
The controls in EliAI are in the ledger. Funding checks the verified filing itself, not a nullable column that says a filing happened. A clinical document cannot be attached to a counterparty file before the agreement permitting it exists, and cannot be back-dated to before it either. A concentration breach refuses the funding at the moment of funding, and names the dimension, the share and the largest advance that would still fit — because a refusal without a number is a refusal somebody will route around.
The audit trail is hash-chained, so each record commits to the one before it and editing a row invalidates every row after it. That turns "has this log been altered" into a question with an answer that does not depend on trusting us. Valuations are superseded and never overwritten: the mark you were shown last quarter is still the mark you were shown last quarter.
None of this is expensive to build. It is only expensive to retrofit, which is why it is worth asking a vendor early — and worth being specific. Not "is it audited" but "what does the funding gate read, and could the thing that writes it also clear it?"