Skansar AI Architecture

The observations below are drawn from public posts by named supply-chain professionals during July and August 2026. We have deliberately not attributed or quoted them. These are people describing their own working conditions, not endorsing a product, and it would be a misuse of their words to place them beside ours. What follows is our synthesis, and any error in it is ours.

The integration wall

Asked what was actually stopping AI adoption, 140 supply-chain chiefs did not name model accuracy. Fifty-six percent named integration with the legacy systems they already run. That figure reaches us through a practitioner's summary of research we have not read in the original: we cite it as reported rather than as established. The advice that followed was unusually candid for the industry: evolve the stack rather than replace it, and build the intelligence as a layer on top of what is already there. The WMS stays. The ERP stays. The spreadsheet everyone quietly depends on stays.

The preparation tax

Practitioners in procurement and planning describe the same division of their day: the decision itself is a small fraction of it. The bulk is collecting data, validating it, reconciling one system's version against another's, and shaping the result into something a person can act on. The opportunity, in their reading, is not a system that decides. It is a system that removes the preparation so that expert judgement has room to operate.

The inbox

A procurement manager put it more concretely: the job is quotes buried in email threads, a lead-time slip mentioned in the fourth paragraph of a reply-all, three open RFQs and no clean answer about who owes what. Pricing sits in forty PDFs. Deviation from standard terms sits on page nineteen of a master agreement. This is not strategy work, and it is where the hours go.

The invisible function

Demand planning, one practitioner noted, is measured by the absence of problems. When it is done well, nobody notices. When it is not, everybody asks why inventory is high, why customers are waiting, why shipments are being expedited. A function whose success is invisible is a function whose value is chronically underestimated, and, we would add, a function whose reasoning is never written down anywhere.

Three things called the same thing

A technology founder working in aviation MRO drew a distinction that most stacks blur. A semantic layer defines your metrics once, so a dashboard and an agent return the same number for the same question. An ontology defines your entities, so that the same physical engine referenced in three different systems is understood to be one engine. A context layer wraps both and answers three questions: who is allowed to see this, where did this figure come from, and what did we already decide.

His test is the sharpest thing we read all month. A semantic layer with no ontology underneath it gives you a confident number for the wrong entity. And an ontology relabelled “context layer,” with no lineage or access policy attached, is a better diagram, not a better system.

The missing why

A related argument concerns the layer that gets skipped entirely. An audit log records that a value changed and who changed it. It does not record why, or what else the decision was assumed to hold true for. That second record, decision memory, is absent from most systems, and the reasons given for its absence are not technical. Nobody asks for it in an RFP. It has no dashboard, because what it produces is the absence of a future problem, which demonstrates badly. And its cost is deferred: a system without it works fine for a year.

The capability gap

Finally, and least tractable: the people who can interrogate an AI recommendation, override it when context demands, and design the workflows that make it useful are not the people the industry hired for. That skill set cannot be bought with a software licence, and it did not exist as domain knowledge two years ago. The sharper form of the argument asks whether an organisation built around managing uncertainty that AI now processes in seconds can be incrementally converted at all, or whether AI-native and AI-enabled are different species.

Line those seven up and the temptation is to file them as a list of separate complaints. They are not separate. They form one system, and the order matters: each band makes the one below it worse.

Fragmented sources and constraining legacy systems produce a day dominated by preparation. Terms that mean different things and entities that do not match produce analysis that cannot be trusted: the confident number computed over the wrong part. Absent context and an unrecorded rationale produce decisions that cannot be defended or reused.

The return path is the part worth dwelling on. A decision that cannot be defended gets made again, and making it again is preparation work. So the third band feeds the first, and an organisation in this state does not drift towards equilibrium, it accumulates. That is a reasonable explanation for why the reported experience is of things getting harder rather than plateauing.

Six of the seven sit below the intelligence. One, the capability gap, is not a band at all: it runs across all three, because the skill to interrogate an answer is what converts any of this into a better decision. None of the seven is a question about the model.

This matters commercially, because it inverts the usual buying conversation. If the binding constraint were model quality, the right move would be to wait for a better model, and the right question to a vendor would be about benchmarks. If the binding constraint is the substrate, a better model changes nothing: it produces more fluent answers over the same unreliable ground.

Our position is that the substrate is the product, and the model is a rendering surface attached to the end of it. The rest of this paper describes that substrate concretely, using our own system and its actual data.

Before meaning, relationships or context, there has to be a curated dataset that is worth reasoning over. Ours is deliberately small and deliberately closed: six datasets covering the value chain end to end, and no seventh.

Six is a constraint, not a milestone. A new reporting requirement is answered with a column on an existing dataset or a composition across several, never a seventh table. The moment the curated layer starts growing per-question, it stops being a shared vocabulary and becomes the same sprawl it replaced.

Every row carries lineage back to the raw asset it came from, and every derived figure carries an evidence state: verified, attested, estimated or missing. That last distinction does more work than any model we could attach. A number that is estimated and a number that is verified are different objects, and a system that renders them identically is lying to its operator regardless of how accurate the underlying estimate is.

The distinction between semantic layer, ontology and context layer is the most useful thing we have adopted from outside our own work this year. Our AI layer is being restructured around it explicitly, because each omission fails in its own recognisable way.

Semantic layer: consistent meaning

One authoritative definition of each term the supply chain is described in. What counts as on-time delivery. What tier means. What makes an item controlled. Varied source fields map onto one vocabulary, and the rule is that a term is defined in exactly one place: the ontology and the context layer reference it and never redefine it. Without this, the same question asked twice returns two numbers, both defensible, and trust collapses on the first discrepancy a user finds.

Ontology: relationships and implications

Typed relationships and the rules for traversing them. Supplier supplies component; component belongs to lot; lot feeds sublot; sublot is assembled into a programme deliverable; certificate covers lot; supplier is located in jurisdiction. Without it, a system can report that a licence lapsed but cannot tell you what that lapse touches. With it, the traversal itself is reportable: not just the conclusion, but the path taken to reach it.

Context layer: situational judgement

Who is asking and what their role permits, which programme is in view, what deadline is live, what the operating rules are. This is the layer that turns a finding into the right recommendation for this person now. It answers the three questions above: who may see this, where did the figure come from, and what did we already decide.

The third question is the one that has no home in most architectures, which is the subject of Section 07.

Everything so far describes what the model stands on. This section describes what it is not permitted to do, which we consider the more important half.

Detection and categorisation are deterministic. A rule catalogue, eleven rules in the running system, evaluates facts from the curated datasets against stored thresholds and produces a categorised risk case. No model participates. The rules are versioned and editable by an administrator without a deploy, so tuning is an operational act with a history, not a code change.

The model writes grammar, not values. When a risk case is rendered into a sentence for an operator, the model never sees the figures. It receives a slot manifest, keys and human labels only, and returns prose containing {{placeholders}}. The server substitutes the real, deterministically formatted values afterwards. Because the model never handles a number, a name or a date, it is structurally incapable of altering one. This is not a policy enforced by review: it is enforced by what the model is given.

A validator rejects any output containing a bare value, a real entity name or an unknown placeholder, and falls back to deterministic prose. In the system state used for this paper, with no model configured at all, that fallback fired seven times and the response payload was unchanged. The AI layer is genuinely optional: turn it off and you lose fluency, not function.

One surface admits no AI at all. The quantitative view, tables, percentages, counts, is rendered directly from facts with no narration, summarisation or model-derived figure, permanently. One fact bundle, two renderers: one produces sentences, one produces numbers, and only the first involves a model.

Sections 03 to 05 describe the layers as a stack. This section describes them as a sequence, because that is how a transmission actually experiences the system. There are eleven stages. The model is the eighth, and it is the only one that cannot change a number.

Stages 1–4: getting to data worth reasoning over

The first four stages ingest raw records from the six source systems, resolve them against the ontology so that the same supplier, component or lot referenced in different systems collapses to one entity, attach lineage back to the raw asset, and mark each derived figure with its evidence state. Nothing downstream is allowed to treat an unresolved or unlabelled record as fact.

Stages 5–7: turning facts into a categorised case

The rule catalogue evaluates the curated facts against stored thresholds, produces a categorised risk case, and attaches the context needed to make that case actionable: who is allowed to see it, what programme it belongs to, and what was already decided about similar cases. None of this involves a model.

Stage 8: the model, and only the model

The eighth stage is the only one where a model is involved, and it is given a slot manifest rather than figures. It writes the sentence around the case. It cannot alter a number, a name or a date, because it never receives one.

Stages 9–11: validation, delivery, and record

A validator checks the model's output for bare values, real entity names or unknown placeholders and falls back to deterministic prose on any failure. The response is delivered to the operator through one of two renderers. The interaction, and the decision made from it, is written back into the record that the next pass of the pipeline will read.

The loop that is not a learning loop

It would be easy to describe stage 11 as the system learning from operator feedback. It does not. What is written back is a record of what was decided and why, available for the next case to reference, not a weight update to the model. The distinction matters: the pipeline gets more useful over time because its memory grows, not because its model changes underneath it.

An audit log answers: what changed, when, and by whom. That is necessary, and we have it on every action. It is not sufficient, because it cannot answer the question that actually arrives eighteen months later, usually from an auditor or a new owner: why did we accept that?

A decision memory record captures the judgement applied around a deterministic outcome: what was decided, by whom, on what evidence and with what evidence state, which alternatives were weighed, and what happened as a result. Decisions supersede rather than overwrite, so the earlier judgement and its replacement are both retained and linked.

Where AI is involved, the record states that AI advised and a named human decided. There is no path by which a decision is attributed to the system. This is partly a regulatory position and partly a practical one: an organisation that cannot name the person behind a judgement cannot defend it, and will not learn from it either.

We should be plain that this layer is specified and not yet built. It is the clearest illustration of the deferred-cost problem described in Section 01: a system without it works perfectly well for a year, and then does not.

What follows is a single thread taken end to end from a running instance. The figures are real outputs of the system described above. The underlying records are seeded demonstration data, not a customer's operation: the numbers are genuine products of the pipeline, not genuine facts about a real supplier.

The instance holds twelve programmes. Three are at risk, down from five over four weeks. Two sit below the EU-origin threshold of 65%, drawing on five connected sources. The nearest audit is an EDIP eligibility review of a programme on 16 August 2026 against control C-EUO-001.

What the data said

EU-origin content for one silicon die, measured across the curated product-design dataset, came to 58%. The stored threshold is 65%, with a red band below 60%. Nothing about that evaluation is a judgement call: it is a comparison between a computed figure and a number an administrator set, and it would produce the same result on every run.

What the rules made of it

The comparison produced a risk case categorised ORIGIN_BELOW_THRESHOLD, banded red, carrying exposure of €1.85M and touching two programmes. It was raised on 29 July and de-duplicated against a key combining the rule, the supplier and the component, so a second detection of the same condition updates the case rather than creating a parallel one. Ten days later, unclosed, it escalated: the case is at level 2 with the next escalation due 8 August.

What the operator was shown

In the Command Centre the same facts surface as a decision with a recommended next action: request origin confirmation from the supplier, and a stated reason for that action: one confirmation re-derives EU-origin across every shared lot. The decision carries the wider blast radius, €4.6M across three programmes, and an evidence state of estimated, because origin has been declared rather than confirmed against a source record.

That last field is the one we would point to. The system is not claiming to know the origin percentage. It is claiming to have computed 58% from evidence it has marked as estimated, and it is recommending the action that would convert that estimate into something verified. A layer that could not represent the difference would have presented 58% as fact.

What happens without a person

Nothing that matters. Auto-executable remediation steps run inside a window the operator can redirect, every one of them audited. The case does not close until a person confirms it. If nobody acts, the clock escalates the case upward through the buyers above rather than quietly letting it lapse: which is the behaviour the “measured by the absence of problems” observation in Section 01 demands, since the failure mode of an invisible function is silence.

Everything above describes a destination. This section describes a route, because the most common failure we see is not choosing the wrong architecture, it is starting at the layer that demonstrates well rather than the layer everything else depends on.

The exit conditions are the substance here, not the increment names. “Ground the data” is a slogan; “the same records produce the same metric and the same denominator” is a test that either passes or does not. An increment without a falsifiable exit condition cannot be finished, only abandoned, and a programme made of such increments reports progress indefinitely.

Note where the model appears: increment five of six. Increments one to four, measuring the preparation cost of a real decision, resolving identity, typing the relationships, moving thresholds into configuration, deliver value on their own and are not blocked on choosing a model, a vendor or a hosting posture. If budget runs out after increment four, the organisation is better off than it started. That is deliberate sequencing, not modesty.

Who owns what

The capability gap in Section 01 is an ownership problem before it is a training problem. Four roles have to exist, and in most organisations three of them are unassigned:

• · Operational experts own the definitions, the exception policy, the decision rights and the outcome review. If a planner cannot change what “on time” means, the semantic layer belongs to whoever can, and it will drift from the operation.
• · Data stewards own identity resolution, evidence quality, and change control over definitions, including the rule that changing a definition creates a version rather than rewriting the basis of past decisions.
• · Architects own tool boundaries, provenance, access enforcement and failure behaviour: specifically what the system does when it does not know.
• · Risk and compliance own materiality thresholds, which actions require human approval, retention, and what an auditor is entitled to see.

Software can make the interrogation skill cheaper to acquire by showing the traversal, the evidence state and the prior decision rather than only the conclusion. It cannot assign these four ownerships, and a deployment into an organisation where they are unassigned will produce fluent answers that nobody is accountable for.

Most AI measurement we encounter reports on the model: acceptance rate, satisfaction, questions asked. Those describe how the interface is being received. They say nothing about whether the decisions got better, and they will look healthy in a system that is confidently wrong.

Measure the operating system instead. These are the indicators we would hold ourselves to, grouped by the layer they test:

Two of these deserve emphasis because they are the ones that fail quietly. Repeat-exception recurrence is the direct measure of the loop in Figure 2: if the same exception keeps arriving, decision memory is not doing its job regardless of how complete the records look. And unsupported-claim rate under adversarial evaluation is the only honest test of the boundary in Section 05: we assert that placeholder narration makes figure tampering structurally impossible, and an assertion of that kind should be attacked deliberately rather than accepted because the design implies it. We have not yet published that evaluation, which belongs in the list in Section 11 as much as anywhere.

Safeguards we would not trade

• · Least-privilege retrieval, enforced where the query executes rather than in the prompt.
• · Evidence state preserved end to end: an estimate never silently becomes a fact.
• · Deterministic controls computed outside the model, always.
• · Explicit human approval for any consequential action, with the human named in the record.
• · Immutable decision lineage; supersession rather than edit.
• · Prompt and policy version captured with every rendered output.
• · Safe abstention: when identity, context or evidence is insufficient, the system says so instead of producing its best guess.

A whitepaper that ends at the previous section would be dishonest about the state of the work. Six things are unresolved, and a reader evaluating us should weigh them.

Inference still leaves the estate

The architecture in Figure 3 places the model inside the trust boundary. Today the call goes to a hosted third-country API. For a customer operating at classification, that is not a tuning issue: it is disqualifying, and it must be replaced by an accredited model hosted inside the enclave before any such deployment. It is tracked as a blocker, not as a backlog item.

Two of the layers are specified, not built

The decision memory layer in Section 07 and the three-layer restructuring in Section 04 both exist as requirements documents. The AI layer as it runs today is closer to intent-keyed assistance than to the fundamental analysis those documents describe. We have published the specifications and the reasoning; we have not yet published the implementation.

Two controls on the model are planned

Text carried inside a partner document should never reach the model as an instruction, and a release crossing an organisational boundary should be checked against the receiving party's clearance and cut to the fields they are entitled to see. Both are designed and neither is implemented. The placeholder mechanism in Section 05 constrains what the model can emit; it does not by itself constrain what reaches it.

The figures are seeded

Section 08 is a real execution of a real pipeline over demonstration data. It demonstrates that the mechanism works and that the numbers are computed where we say they are. It does not demonstrate accuracy against any real supply chain, and we would resist anyone citing 58% or €1.85M as evidence about a supplier.

The integration wall is narrowed, not removed

Building intelligence as a layer over systems that stay in place is the right shape, and it is the shape we chose. It is still integration work. A first connection to an ERP or a PLM is measured in weeks, not hours, and anyone quoting hours is describing a demo. What the framework buys is that the second and fifteenth connections cost a fraction of the first, because identity, staging, validation, retry and audit are already solved.

We cannot sell you the capability

The seventh problem in Section 01 is the one no vendor can close. People who can interrogate a recommendation, override it on context, and design the workflows around it are built inside an organisation over years. Software can make that cheaper by being interrogable: by showing the traversal, the evidence state and the prior decision rather than only the conclusion, and that is a real design objective for us. But a licence does not produce the skill, and a paper that implied otherwise would be selling the thing the practitioners specifically warned about.

The practitioners quoted in aggregate at the start of this paper are describing a market that has spent several years optimising the visible layer and skipping the ones underneath. The costs of that are deferred, which is exactly why it keeps happening: a system with no consistent semantics, no traversable relationships, no access-aware context and no memory of its own reasoning works acceptably for about a year.

Our bet is that the durable product is the substrate: the curated datasets, the deterministic rules over them, the lineage and evidence state attached to every figure, and the record of what was decided and why. The model sits at the end of that chain and writes the sentence. It is genuinely useful there, and it is replaceable there, which is the point. If the model can be swapped, or switched off entirely, without changing a single number the operator sees, then the value was never in the model.

That is a testable claim rather than a marketing one, and Section 05 records the test: with no model configured, the system fell back seven times and returned the same payload.