A Reasoning Engine That Refuses to Guess:
AGORA and Process Exegesis
A language model asked about your loan approval process will answer. It will answer fluently, in your vocabulary, with plausible numbers. Whether it has ever seen your process is not something the answer tells you, because the answer looks identical either way.
That is the property that makes general models unsuitable as the explanatory layer over a regulated business system. Not that they are wrong often - they are right a great deal of the time - but that being right and being wrong are indistinguishable at the point of reading. A compliance officer cannot act on a sentence whose confidence is uncorrelated with its correctness.
AGORA is our answer, and the design starts from an unusual constraint: it must be structurally incapable of stating a number it did not measure. Everything else follows from that.
Contents
- Exegesis, not generation
- Your models are the structural prior
- Grounding: looking words up rather than inferring them
- The curiosity loop, and asking one question at a time
- Continuous alignment auditing
- The fidelity gate: fails closed
- Learning without backpropagation
- How this differs from an LLM, and where an LLM wins
- What is built, what is tested, what is designed
1. Exegesis, not generation
Exegesis is the discipline of drawing meaning out of a text that is already there, as opposed to composing a new one. The distinction is exactly the one we need.
A generative model produces the most plausible continuation. An exegetical engine produces an account of something specific, and every claim in that account traces back to a place in the source. When it does not know, there is no plausible continuation to fall back on - the source either says something or it does not.
AGORA's sources are your formal models - the ArchiMate architecture, the BPMN, DMN and CMMN definitions, the integration topology, the UI models - plus the execution history of the processes those models describe. Its output is an account of what those say and what the executions did.
2. Your models are the structural prior
A language model's prior is a very large amount of text. AGORA's prior is your architecture.
When a domain is loaded, each modelling layer contributes structure: the architecture layer contributes districts for goals, capabilities, services and their relationships; the process layer contributes tasks, gateways and events; the integration layer contributes channels, routers and endpoints, plus edges that cut across into the business layer; the UI layer contributes view containers and actions and the edges that connect them to processes.
This is the substitute for pretraining, and the trade is worth stating plainly. A pretrained model knows a great deal about loan approval in general and nothing about yours. AGORA knows nothing about loan approval in general and a great deal about yours - specifically, the exact vocabulary your architects chose, the exact structure they declared, and the exact paths your executions have taken.
For a system whose job is to explain this business to the people who run it, the second kind of knowledge is the useful kind. General knowledge about lending is what makes a general model sound convincing when it is inventing your policy.
3. Grounding: looking words up rather than inferring them
Business models are full of terms nobody defined. A process step called "perfect the security interest" is meaningful to a lending lawyer and opaque to everyone else, including a system trying to explain the process.
A general model handles this by inferring from context, which works until it does not and is never marked. AGORA does something duller and far more auditable: it detects that a term is not grounded, and looks it up.
Two details make this more than a glossary lookup.
First, provenance is structural. A grounded term does not carry its source as a metadata field alongside the meaning; the source, the definition and the confidence are bound together into the stored position in a way that can be decomposed. Asking "which of these meanings came from a dictionary rather than from a human?" is an operation on the representation, not a filter on a column somebody might have forgotten to populate.
Second, lookup is a real network call to a real dictionary, not a recollection. The engine fetches definitions from public dictionary APIs at a polite rate. When it tells you what a term means, there is a URL behind it.
In a representative run against a lending domain, this grounds on the order of a hundred and fifty terms automatically. The rest become questions.
4. The curiosity loop, and asking one question at a time
Terms the dictionary cannot settle - which is most of the genuinely domain-specific ones - go to a queue of questions for a human. The queue is asynchronous by design: nothing blocks, and the questions get answered when someone has time.
The mechanism that decides when to ask is itself a Petri net, which turns out to be the natural formalism for it. Two of its properties are worth describing because they encode a judgement about being a tolerable colleague rather than an annoying one.
One question at a time per term. An inhibitor arc prevents a second question about a term while the first is still pending. It is structurally impossible for the engine to ask you three variations of the same question because it forgot it already asked - not unlikely, impossible.
Curiosity anneals. The gate on asking starts permissive and becomes progressively more selective as the domain gets better understood. Early on the engine asks freely, because everything is new and you are expecting to teach it. Later it asks only about things that genuinely matter, because by then an interruption has a real cost.
Questions are prioritised by how often the term appears and how critical the process it appears in is, so a term blocking a compliance path outranks one in a rarely-used branch. Unanswered questions expire after a week and requeue at lower priority rather than nagging.
5. Continuous alignment auditing
Because AGORA has read every layer, it can run the cross-layer alignment queries described in the BQL article continuously rather than at review time: goals nothing realises, processes nothing can start, services with no endpoint, endpoints serving no service, constraints that executions are getting past, screens backed by nothing.
Each finding is bound to the specific element it concerns, so an explanation decomposes: not "there are 14 alignment gaps" but "this goal, declared here, is realised by nothing, and here is the capability that was supposed to."
This is the difference between a dashboard and an account. A count is a thing you look at. A decomposable finding is a thing you can act on, and the difference matters most exactly when the number is large.
6. The fidelity gate: fails closed
This is the mechanism the opening constraint reduces to, and the single most important thing in this article.
When AGORA renders a finding into a sentence - in English or in French - the sentence passes through a gate before anyone sees it. Every magnitude and every named entity in the prose must reconcile against the measurement carried on the finding itself. If a number appears in the sentence that is not on the finding, or an entity is named that the finding does not reference, the sentence is discarded and replaced by a faithful, unlovely dump of the measurement.
The gate fails closed. Ambiguity produces the dump, not the prose. That is a deliberate and slightly uncomfortable choice, because it means the system sometimes hands you something ugly when a perfectly good sentence was available. We prefer that failure to its opposite.
It is worth being precise about what the gate does not do. It does not police tone, emphasis or framing. A sentence can be poorly worded, badly emphasised or unhelpful and still pass, because every number in it is real. The gate is a guarantee about facts, not about quality. Claiming more than that would itself be the kind of overstatement it exists to prevent.
But the guarantee it does make is the one that matters for this class of system: a number in the output was measured. Not inferred, not interpolated, not plausible. Measured.
7. Learning without backpropagation
AGORA learns, and it does so without gradients. Four mechanisms operate directly on the substrate.
- Co-firing association. Things that occur together strengthen their connection - the oldest idea in learning, applied to the structures your models declared.
- Positional drift. Positions in a district migrate under the pull of what they co-occur with, so the geometry adapts to how the vocabulary is actually used rather than to how it was initially assigned.
- Spectral reorganisation. Periodically the district reorganises along its dominant directions of variation, computed in a streaming fashion rather than over a stored dataset.
- Trajectory learning. Execution paths themselves are training signal - on the order of ten thousand trajectories in a single demo run.
Why avoid backpropagation? Not out of purism. Because these mechanisms are incremental and local. There is no training run, no checkpoint to version, no retraining window during which the system knows an older version of the business. The engine learns while it runs, one observation at a time, and a change to one district does not perturb the others - which is the same modularity argument that shapes the store underneath, described in The Beam and the Dark Space.
8. How this differs from an LLM, and where an LLM wins
| General language model | AGORA | |
|---|---|---|
| Prior | A very large text corpus | Your formal models |
| Breadth | Nearly anything | These processes, and nothing else |
| When it does not know | Produces plausible text | Queues a question, or emits the measurement |
| Numbers in output | May be generated | Reconcile to a measurement or the sentence is discarded |
| Provenance | Not generally recoverable | Structural, decomposable by role |
| Learning | Training runs and checkpoints | Incremental, while running |
| Fluency | Excellent | Adequate, and deliberately capped by the gate |
Read the last row as seriously as the rest. A general model writes better prose than AGORA does, and it will keep doing so. If your problem is summarising a document, drafting a response, or reasoning across a domain nobody has modelled, use one - it is the right tool and we are not going to pretend otherwise.
The claim here is narrower and, we think, more defensible: when the question is "what did this specific regulated system actually do, and what is missing from it", the property you need is not fluency. It is that the answer cannot contain a number nobody measured. Those are different products, and the honest position is that most organisations will want both, pointed at different problems.
9. What is built, what is tested, what is designed
An article about a system that refuses to overstate should not overstate the system. Three tiers, and we hold ourselves to them internally with an automated check that every claim of this kind corresponds to code that exists.
| Status | What it covers |
|---|---|
| Running in the demo | Domain composition; continuous intake of text; the architecture, integration, UI and process contributors; dictionary grounding; the curiosity loop and question queue; continuous alignment auditing; the four learning mechanisms; operational instrumentation; and the rendered outputs behind the fidelity gate. |
| Tested, not on the default path | The substrate-native generation pipeline - composing sentences from the geometry rather than filling templates - and its cross-lingual behaviour. Passing tests, reachable behind a flag, not what the demo runs. |
| Designed, not built | Multi-sentence discourse, the inverse parser that would turn a sentence back into a situation, voice surfaces, non-Latin phonetics, and grounding shared across tenants. |
Two further limits worth stating. One dimension of the deviation taxonomy is designed rather than learned - it lifts a categorical label rather than a descriptor the system worked out - so verdicts depending on it are honestly unknown rather than quietly confident. And none of this is on the public API surface today; it runs inside the product.
Conclusion
The uncomfortable fact about fluent systems is that fluency is orthogonal to correctness, and readers cannot tell the two apart. Everything in AGORA's design is a response to that:
- Exegesis over generation. An account of specific sources, not the most plausible continuation.
- Your models as the prior. Nothing about lending in general; everything about yours.
- Look it up, or ask. Grounding from real dictionaries with recoverable provenance, and a question queue for what they cannot settle.
- A gate that fails closed. A magnitude that does not reconcile costs you the sentence, not the accuracy.
A system that says "I have not seen enough of this to have an opinion" is less impressive in a demonstration and far more useful in front of an auditor. That trade runs through this whole stack - it is the same three-valued answer the anomaly detection layer gives, and the same refusal to let an absence of evidence quietly become a finding.