Why start from an Ontology
Before Siege builds a screen, a table or an agent, we write down what the business is, in a form both a person and a machine can read. That written model is the Ontology. Every screen, table and agent is built from it and checked against it.
Most business software grows outwards from its screens. One rule ends up in four places: the screen that shows it, the column that stores it, the report that counts it, and the head of the person who knows the exceptions. The copies drift apart until nobody can say for certain what the system does, and every change becomes a risk.
An ontological approach turns that order round. First come the kinds of things the business deals with: for example, customers, orders, jobs, approvals and invoices. Then what is true of each, how they connect, what may change, and who may change it. Only then do we build. The screens, the data model and the agents are readings of one statement, not separate creations we hope will agree.
What this gives the business:
What the system does is written down in one place. It is in the Ontology, in the business's own words, and the owner can read it.
The effect of a change is known before it ships. A change is stated once, and everything that depends on it is identified and checked before release.
The description of the business is independent of Siege. The Ontology is kept in an open W3C standard (RDF/Turtle) that standard tools read without Siege's software.
Agents work from the same rules as the software. An agent is given the model's own statement of the rules it works under, and every action it takes is checked against those same rules.
A clean Ontology
An Ontology only helps if it is clean. Ours are held to a written modelling standard, and a change that breaks it is refused at once, with the reason in plain words. Two examples: every fact is said once, so the model never holds two copies of it; and nothing that can be worked out is stored, so no stored value can contradict the facts it comes from.
What is built from the Ontology
What is built from it | What it guarantees | What an adviser can check |
|---|---|---|
The data model | Every table and column answers to a named fact in the Ontology | Every database change names the model revision it came from, and the client's deploy refuses one that was not written from the client's own Ontology at a revision on its live model |
The actions people take | What each action changes, and what must be true before it can happen | An action whose conditions are unmet is refused, and the refusal names the condition |
The screens | Each screen holds what its area of work needs, and only that | A screen's contents trace back to the part of the model it reads |
The agents | The keys each agent holds, what it may read and do, are written in the model, and nowhere else | An agent's keys are read in one place, and a change to them is checked like any other change |
Guarantee
From day one, each client's build plan says which layers are generated from the model and which an engineer writes from it. Whichever way a layer is made, what it lets people and agents do is tested against the model before the client relies on it, and again whenever the model changes. What each screen shows is checked against the model in review.
Who is in the model
No individual is an actor in the model; a decision records who made it. The model names two kinds of actor.
Personnel Archetypes are the kinds of people who work in the business: sales, operations, field staff, accounts. An archetype carries what that kind of person may see and do. A person holds an archetype, so staff join, leave and change roles without any change to the model.
Agents are AI workers the business can add once its application runs. Each is an actor of its own, never a borrowed login and never an extension of a role. Each agent holds its own keys and nothing more, and a change to them goes through the same checks as any other change.
Every action records who took it: a person, through their archetype, or a named agent. The two are never confused. A rule never names whoever happens to approve today; it names the kind of person who approves, so it outlives any one person.
Agents stop; people are warned
Some rules are firm. Others are rules a fast-moving shop sometimes has to step past ("ship before the final invoice goes out, the customer is waiting"). At such a rule, a person is warned and may go ahead, and the override is recorded with who, when and which rule they stepped past. An agent is always refused there, as it is at every other rule.
Every change is checked, versioned and reversible
The Ontology is the business's operating truth, so a change to it is controlled like a change to production.
Changes are prepared apart from the live model. Every change is prepared on a working copy, and Siege approves each change to a client's live model. Where a change turns on a fact about the business that only the client knows, Siege asks, and records the answer with who gave it and when.
One way in. A change enters only through a single checked entrance. One that breaks the standard above, or contradicts a business decision that can be checked, is refused there, with the reason in plain words.
It lands only when every check passes. A change joins the live model only when the cross-checks between the Ontology, the order of work and the application come back clean. The evidence stays on the record. A change that carries real risk to existing data needs a named person's explicit acknowledgement; no agent and no Siege software can give it.
Every revision is numbered and kept, with what moved, who moved it and why, in one line anyone can read. Any revision can be exported whole, so two can be compared with standard tools.
Reversible. Every earlier revision is kept whole, so any change can be undone by a new revision that passes the same checks. Existing data moves the same careful way: the new place is added, the data is carried across, and only then is the old place retired. Nothing is dropped while anything still depends on it.
Machine guesses are marked. Anything a machine proposed stays marked unverified until a person confirms it: Siege checks it, and a fact about the business is confirmed by the client, recorded with who and when.
A change to the live model is never erased or rewound; it is reversed only by a further revision on the record. Every agent acts only within its own keys and under the rules on this page. Stepping past a rule, acknowledging a risk, and sending anything to a customer stay in a person's hands.