Ontology, Gates, and a Human Backstop: Three Defenses for Enterprise AI That Don't Spin Empty

2026-10-05

Enterprise AI usually lands in one of two extremes.

One side says: build the ontology and the AI will understand. The other says: an ontology is soft, it cannot hold the line, and what matters is gates plus a human backstop.

Each side is only half right.

An ontology makes it possible for the AI to get it right. A gate makes it hard for the AI to do the wrong thing on its own. A human backstop keeps a mistake from becoming a disaster. Use the three together, and close the loop: the ontology hands objects and rules to the gate, the gate hands anything out of bounds to a person, and after the person handles it they ask whether a term or a threshold should change. Without that return path, people keep putting out the same fire.

The weight shifts with the scene. The short board sets the ceiling. High frequency, low risk, reversible: the ontology and automated gates set the experience and the cost. Low frequency, high risk, irreversible: the gate and the human backstop are what keep you safe. Heavy regulation and heavy responsibility: all three have to be hard. Open questions can tolerate a wrong answer. Data that should not enter the context still has to be stopped.

Whether this works is not a question of whether the article is complete. It is whether the three tables can be filled in for one concrete scene. A cell you cannot fill means that question may not be answered, and that action may not be taken.

1. What each layer handles

Layer	What it handles	When it fails
Ontology	Whether the system understands	The answer is fluent, and wrong
Gate	Whether it may, and whether the figure is the right one	It acts at random, exceeds its authority, or does something irreversible
Human backstop	Who is responsible, and how a mistake is written back	The damage cannot be undone, and the same kind of mistake keeps returning

Do not ask which layer matters most. Ask which layer is the short board in this scene, then ask whether that layer's table is filled in.

2. Ontology: start from a specification

An ontology here is a business specification: what a word means, what it does not mean, and which field on which document the figure comes from. It is soft, like an employee handbook. It does not itself block an action. The part that can be made hard has to become a check outside the model.

Split the content into two kinds first:

Kind	Where it lives	What a mistake does
Helps the model choose the right meaning	Terms, relations, definitions. The model may read them	The wording drifts, and can still be corrected
Must not be allowed to happen	Written as a program check	The action cannot occur

"Collected payment is not the invoice amount" is the first kind. Putting the words in a table does not stop the model from answering with the invoice amount. A wrong figure is stopped by the input gate: what is handed to the model this time contains only the field named on the authoritative source. The invoice amount is not included.

"Do not send it to the customer on their behalf" and "do not pay above this amount" are the second kind. Written into the prompt for the model to obey on its own, they are still soft.

Each common word gets four lines: how people say it, what it is, what it is not, and which field on which document is the authoritative source. "What it is not" matters most.

One word binds to one authoritative source. If a finance definition and a management definition are both legitimate, they are two words. Do not switch sources on the same word. When two owners disagree, follow the owner of this word, the person on the side of the authoritative source. When the definition changes, new documents use the new version. Documents that already happened keep the old version.

If the source has no record yet, the answer is "no figure yet." Do not fill it from another set of books. Also write how long the business can wait. If the wait expires and there is still no figure, point to a named person. Do not repeat the same sentence. If the wait is not written down, people will go look somewhere else, and this gate has nobody walking through it.

Write only relations that have actually been asked. Three to five is enough. Write the rules, and mark which kind each one is. A rule of the second kind lands on a gate at that moment.

Each word has an owner, an update trigger, a version, and a minimum set. It also has a reviewer and a review cycle. A trigger without a review lets the table go stale when nobody reports an error.

3. Gates: start from what is forbidden

Write what must never be done: which fields cannot be changed, which approvals cannot be skipped, what cannot be sent outside, which tools cannot be called, and above what amount a person is required. Talk about permission only outside that forbidden zone.

Level	What the system does	What the person does
Read only	Looks up and answers	Judges for themselves
Suggestion	Offers a suggestion	Does the thing themselves, including sending it
Confirmation	After the person agrees, the system does it	Agrees, and is responsible for what cannot be undone
Automatic	Does it directly, and leaves a trace	Can be inspected afterward, and can be rolled back
Forbidden	Does not do it	Not applicable

Anything not explicitly allowed is forbidden. If read-only is enough, do not grant a write. An automatic action must be reversible or have a remedy. The judgment sits outside the model. Waiting for a person has a time limit. When the time is up, the action stops. A stop is not the same as a person refusing, and it must not be turned into an automatic action.

Use the checkpoints the scene needs. All seven are not required:

Checkpoint	What the program does
Input gate	Which documents and which fields are allowed this time
Term gate	Checks an allowlist. Which words a conclusion may use is written in advance, and so is which slots the output has
Tool gate	Which tools may be called, and whether the parameters are allowed
Action gate	Which fields may change, and which states may move
Approval gate	Above a threshold, across parties, or outside the country, hand it to a person
Provenance gate	Compares only fields that have already been written down with the authoritative source
Audit gate	Who let it through, when, which version of the terms, which document

The term gate does not guess afterward which word the conclusion depended on. That falls back to letting the model judge for itself. The allowlist and the output shape are written first.

The provenance gate compares fields only. In collections, the amount, the customer, and the invoice number can be cells. The suggested wording is not compared. An analysis, a long conclusion, or a judgment tangled in several conditions cannot be made into stable fields, so do not install this gate there. Those scenes keep the input gate, the forbidden zone, and the audit. The conclusion stays with a person.

A confidence score the model reports about itself is not a gate.

To rise from "the system acts after a person agrees" to "the system acts on its own," write five things first. The count comes last:

• What counts as one error. If that is not written, a count means nothing
• Who decides it was an error. What they check against, and how much time is set aside for that check. If nobody decides, the action stays at its current level. A name with no time is only a stamp
• The sample has to cover the main situations of this kind of action. A pile of easy cases is not enough, even if the count is large
• The action can be undone, or has a stated remedy
• If it errs again, it drops back one level

Low-frequency, high-risk, irreversible actions do not become automatic by accumulating a count.

4. The human backstop: the last layer

It has to exist. It cannot be the main path. People are expensive, they get tired, and they spread the responsibility thin.

Kind	What it does
Exception handling	Handles what a gate stopped, and what the program cannot match
Responsibility	Signs for an irreversible action
Return path	Decides whether the terms change, or the gate changes. If neither changes, write the reason

Escalate only when the case hits the allowlist, an approval, or provenance. Each backstop has a handler, a time limit, a next person, and someone who counts whether the time was exceeded. If nobody counts, the time limit is empty.

While the system only suggests and the person does the thing themselves, whether the amount was stated wrong is compared by the program. Do not ask another department to certify the sending. Certification is only for what the program cannot see: a source delay the business will not accept, or a disputed definition. Once the system sends on its own, a sending error needs a separate person to certify it, and that person needs the time above.

5. Fill the tables once, with collections

The scene is fixed. A salesperson asks about a customer's collected payment. The system answers from the finance receipt only, with an amount and a suggested wording. The salesperson decides whether to send it, and sends it themselves. This is a suggestion. It is not "the system sends after someone nods."

This scene has four output slots: customer, booked amount, whether anything is still unbooked, and suggested wording. The only conclusion word on the allowlist is "collected payment."

What can be filled in:

Item	Decision
What collected payment is	Money the customer actually paid into the company account
What it is not	Not the invoice amount, not the contract amount, and it does not include prepayment
Input	Only the booked amount on the receipt. The invoice amount is not included
Sending	No send tool. The system does not change the document
Provenance	Compare only the customer and the booked amount. Do not compare the wording
Unbooked	Say "no figure yet." Do not fill it with some other number
Level	Stays at suggestion. It does not rise

Empty, and therefore not allowed yet:

Empty cell	Therefore not allowed yet
Which system holds the receipt, and which field	The input gate cannot be drawn, so the amount cannot yet be a formal answer
How a customer id matches a receipt	Do not answer "this customer's collected payment"
How an invoice matches a payment received	Do not answer "whether this invoice has been paid"
Which day overdue starts, and after how many days it counts	Do not answer about overdue
How late the source may be	"No figure yet" cannot go live yet, or people will go around it
Who handles a mismatch, how long, whom they call, who counts timeouts	The backstop is only a name so far
Who reviews the three tables, and how often	The tables are not built yet
What counts as one error	The system does not send on its own yet, so this may stay empty. It must exist before the system sends

A management definition is a different word. This scene does not ask it, so that row is not built.

6. Different scenes trim the tables

The three tables are one way of filling things in. They are not a full copy for every line of business.

Scene	How the tables are used
Documents, processes, and fields are clear	The input gate, the allowlist, the provenance gate, and the audit gate can be used together
Low frequency, high risk, irreversible	Keep the forbidden zone, approval, and a signature. Do not schedule automatic action
Open questions, analysis reports	Keep the input gate, the forbidden zone, and the audit. Do not turn provenance into fields. A person owns the conclusion
Heavy regulation, accountability required	Every row used above needs a version, a person who certifies, and a review

Consider automatic action only for something that can be undone, and only after "what counts as one error" is already written.

7. Order of landing

1. Pick one scene. Write the terms and the forbidden zone first. Mark which of the two kinds each rule is.
2. Fill the three tables. A question you cannot fill in is removed from what may be answered.
3. Go live as read-only. Use a fixed set of questions to see whether the error is the definition, the wrong field, or a missing source.
4. Suggestion: the system suggests, the person acts.
5. Confirmation: the system acts after a person agrees. The person who certifies, the time limit, and the person who counts timeouts already exist.
6. The error definition, the sample, and the rollback are written before automatic action is considered.
7. Every backstop returns. On the review day, look for a stale table even if nobody reported an error.

Those are the column headers. Delete rows the scene does not use. Do not leave a gate that nobody walks through.

Ontology: term or rule, kind, definition, what it is not, authoritative source and field, owner, how to answer when there is no record yet, how long to wait, update trigger, version, reviewer and cycle.

Gate: checkpoint, rule, where the line is drawn, what happens after a stop, who agrees, who certifies an error, what happens when time is up, the log, whether it can be undone, the error definition required before a level rises, rollback, reviewer and cycle.

Backstop: what was hit, who handles it, how long, whom they call if they cannot, whether the term changes or the gate changes, whether it was finished, who counts timeouts.

8. Close

An ontology lets the AI know the business. A gate keeps the AI from acting at random. A human backstop keeps a mistake from becoming a disaster. The return path keeps the same kind of mistake from repeating.

If the tables for one scene cannot be filled in, the three layers are not there yet. The empty cells are the boundary of this defense.