AI System Registry

Curated preview surface: answers a fixed set of demonstration prompts from a pre-approved response catalogue. Not connected to a live model. Retained as a UX preview while the Assistant panel Gold Agent (below) becomes the primary chat surface.

Inputs

• The user's question text (matched against a fixed intent catalogue).
• No live data lookup; responses are static.

Output

One of a small number of pre-authored responses. Every response is labelled as AI-generated per Art. 50 via <AiDisclosureBanner />.

Human oversight

No live model output. All response text is pre-authored by the DefenceOS team.

Training & data

None. The response catalogue is hand-written; no foundation model runs at request time.

Limitations

• Only recognises a small set of demonstration intents; any other input returns a default response.
• Does not reflect real-time data — outputs are illustrative only.
• Will be retired once the Assistant panel fully replaces this surface.

Generates a natural-language summary and key-insights for the page/section the user is viewing, using only the caller's already role-scoped and tenant-isolated data.

Inputs

• The current page's role-scoped, tenant-isolated context (already filtered by the API layer to what the caller can see).
• A trigger — either automatic on tab open (Summary tab) or user click (Section Insight, Detail Modal).
• Optional user follow-up prompt.

Output

A structured summary (overview + section highlights + suggested next actions). Rendered via SafeMarkdown so any raw HTML in model output is escaped, not executed. Labelled AI-generated per Art. 50.

Human oversight

Advisory only. No operational action is taken on the basis of a summary. Users can dismiss and can request a human review by contacting the appeal address below.

Training & data

Third-party foundation model (Anthropic Claude, accessed over API). No user data is used to train the foundation model. The model sees only the request-time context supplied by the SSR page.

Limitations

• May produce confident-sounding but incorrect statements (LLM hallucination). Verify against source records for any consequential decision.
• Scope of the summary is bounded by the page's context — insights outside that context are not considered.
• Non-determinism: two runs on the same page can produce different summaries.

Tool-using AI agent that answers natural-language questions by running read-only SQL and structured tool calls against the caller's accessible data, grounded in the current page context.

Inputs

• The user's question text.
• The current page's context, used to ground the agent's queries.
• Read-only tool access to the caller's tenant-isolated data (SQL runner + a fixed set of structured retrieval tools).

Output

A natural-language answer, optionally accompanied by a structured visualisation payload (bar / line / metric / table) rendered by VizRenderer as plain SVG. Labelled AI-generated per Art. 50.

Human oversight

Advisory only. Tools are read-only — the agent cannot write, mutate, or delete. Users can pin a viz to their dashboard, which is a user action, not an agent action.

Training & data

Third-party foundation model. Tool schemas are hand-authored and audited; the agent cannot call arbitrary code. All queries execute under the caller's identity — the same authorisation policy that gates the rest of the API applies.

Limitations

• LLM hallucination in the natural-language wrapper is possible even when tool output is correct.
• SQL tool timeouts / partial results are possible on large joins.
• Page grounding may bias answers toward the currently-viewed slice — ask broadly for cross-cutting insights.
• No memory across sessions.

Selects widgets from a fixed pre-approved catalogue based on a natural-language description of what the user wants to see, then hands the resulting layout to the standard widget renderer.

Inputs

• User's natural-language dashboard description.
• The fixed widget catalogue (bounded selection space — the model cannot invent widget types).

Output

A JSON dashboard spec naming which widgets from the catalogue to render. The frontend renders each widget from the existing (stand-in gold) data.

Human oversight

User reviews the built dashboard and can edit widget selection, reorder, or discard entirely. Falls back to a sensible default set when AI is not configured.

Training & data

Third-party foundation model. No user data is used to train the model.

Limitations

• Bounded to the widget catalogue — cannot compose new widget types.
• May pick a suboptimal combination for a given description.
• Selection is deterministic-ish but not guaranteed across runs.

Reads uploaded supplier documents (certificates, bills of materials, purchase orders, inventory tables) into tables, proposes which type each document is, and checks each one against the published rules for its type — reporting what it finds as ranked findings for a person to rule on.

Inputs

• The uploaded documents in the set being analysed, and the values read from them.
• The published rule set for each document type, which is fixed and inspectable rather than inferred.
• The company context the user has optionally written — free-text guidelines and a list of priorities.
• No other document set, and no other organisation's data.

Output

A proposed document type per file, values marked with an evidence state, and findings ranked red / amber / green. Findings come in two classes, and the interface names which is which on every one. A **rule finding** is raised by a published rule: it names that rule, cites the exact rows, and can be reproduced exactly from a stored record of the run. An **AI observation** is raised by the model reading the table against published domain knowledge and the company's own stated context — it reaches judgements no published rule expresses, and it names the knowledge it reasoned from so a person can disagree with that specifically. Both are labelled as AI-involved per Art. 50.

Human oversight

Nothing the analysis produces takes effect on its own. A finding stays 'proposed' until a named person confirms, downgrades or dismisses it, and only confirmed findings reach the action plan — dismissing one removes it, because the plan is derived from the rulings rather than stored separately. A document whose type was classified with low confidence cannot proceed until a person sets the type, since a document checked against the wrong rules produces confident findings about the wrong thing. **An AI observation carries a further limit that the interface states on the observation itself: it cannot close a compliance question on its own.** Because it cannot be reproduced exactly, it cannot be evidenced later, so its only outcomes are to be confirmed as a named person's own judgement or dismissed with a reason. Where an observation recurs and keeps being confirmed, the interface offers to draft a published rule from it, which moves it into the reproducible class.

Training & data

Third-party foundation model. Document content is supplied as data for the analysis of that set and is not used to train the foundation model.

Limitations

• The rules are deliberately shallow and are not a substitute for a qualification review. The absence of a finding means the published checks passed, not that the document is sound.
• Classification from a filename is a weak signal, which is why the user is asked to confirm it rather than told what it is.
• Context shapes how severely a finding is ranked; it cannot make the analysis check something the rules do not cover.
• A value that is wrong but plausible will be read, ranked and reported as if it were right. Only a comparison against the original document catches it.
• An AI observation is a judgement, not a check. Running the same analysis again may not produce it, and it cannot be replayed from a record the way a rule finding can — which is precisely why it is barred from closing a compliance question.
• An observation reasons from published domain knowledge and from what the company has said about itself. Where either is wrong, the observation inherits that error, which is why it names both rather than presenting a conclusion on its own authority.
• **Pilot limitation:** sets are held in the browser on one device. Rulings taken here are not yet written to the platform audit trail and are not visible to colleagues.

Identifies the step that closes a finding no published rule covers. Every finding already carries an action, but where no rule names one, the platform falls back to a general step keyed only on the kind of problem — 'read the value from the source document and enter it' — which is true of very many findings and useful for none of them. This system proposes a specific step, grounded in the rows, columns and values the finding itself cites, so that a person reading the finding is told what to do about their own data rather than about data in general.

Inputs

• The finding's own evidence: the rows and columns it cites, the values in those cells, how many rows are affected, the kind of document, and the column's label.
• Nothing else. No other finding, no other document set, no other organisation's data, and no free-text company context.
• **Nothing at all for a document classified above the hosted-inference ceiling.** Where any document a finding rests on is EU-controlled or NATO Restricted, no request is constructed — the decision is taken in the engine, before a prompt exists, rather than by asking a model not to look at something already sent.

Output

One sentence naming the step, together with the role that owns it, the number of days it is expected to take, and which of six fixed action kinds it is. The step is refused and the platform's own step kept whenever the reply is over-long, contains markup, describes a different action kind than it claims, asks for nothing, states a window outside 1–90 days, or names a figure, part number or document that was not in the evidence sent — the last of these being the check that stops an invented part number appearing beside a real finding. Every proposal is labelled AI-generated per Art. 50 and carries the model id and prompt version that produced it.

Human oversight

A proposal is never executed and never auto-confirmed. The finding stays 'proposed' until a named person confirms, downgrades or dismisses it, exactly as before, and only a confirmed finding reaches the action plan. **A proposal can never replace a remedy a published rule named** — that is enforced in the type system rather than by convention: the constructor that applies a proposal returns the rule's own action unchanged when handed one, so a rule-authored step cannot be overwritten even by a caller that asks for it. Where a proposal is withheld or does not arrive, the platform's deterministic step stands and the interface says which of the two happened, so a reader can tell a control that fired from a model that was simply not asked.

Training & data

Third-party foundation model (Anthropic Claude, accessed over API from the DefenceOS engine, never from the browser). The finding's evidence is supplied as data for that one proposal and is not used to train the foundation model.

Limitations

• A proposal is a suggestion about remediation, not a check. It cannot raise a finding, cannot change a finding's severity, and cannot close a compliance question.
• Non-determinism: two analyses of the same documents can propose differently worded steps, different owners and different windows. The finding, its severity and the rows it cites do not vary.
• It reasons only from the evidence it is given. Where the extraction read a value wrongly, the proposal will address the wrong problem confidently.
• **Findings on EU-controlled and NATO Restricted documents receive no proposal at all**, by design. Those findings keep the platform's general step, which is less specific — that is the cost of the control, and the interface states it on the finding rather than leaving the reader to infer it.
• Where the model is unconfigured, egress is disabled, the engine is unreachable or the reply is refused by validation, no proposal is made and the deterministic step stands. This is the ordinary case, not an error state.

Looks across a whole evidence pack for supply-chain problems that no published check can express, because they are relationships between documents rather than properties of any one of them — a quality registration that lapsed before the delivery dates on an open order, one casting lot released into two programmes, content below a funding floor because a sub-tier re-sourced while the declaration still carries the old country, a mill in a jurisdiction last screened years ago on material still in stock. Each of those is two individually valid documents and one unacceptable position: nothing in either document is wrong, so no check applied to either alone can see it. This system exists for exactly that gap and for nothing else — it is instructed not to report data-quality problems, which the published checks already cover.

Inputs

• Derived facts about the pack, in the platform's own words: what each published check concluded, how many rows each table holds and under what headings, what kind of document each file was declared as, and the company's own stated priorities.
• The platform's standing knowledge about defence supply chains — statements that ship with the product and are true before anything is uploaded — minus any the user has set aside. A statement somebody has set aside cannot be cited, and an observation citing one is refused rather than filtered, so it cannot return as a finding by another route.
• **Nothing whatsoever derived from a document classified above the hosted-inference ceiling.** Where a document is EU-controlled or NATO Restricted, no fact about it enters the request — not its headings, not its row count, not the findings raised on it. The decision is taken in the engine, before a prompt exists. A finding's own words routinely quote the cells that raised it, so 'derived' earns no weaker treatment here than a raw cell would.
• Never sent: the documents themselves, any cell the platform did not already put into a finding, filenames, row identifiers, the name the user gave the pack, or the company identity.

Output

At most six proposed observations, each with a title, the concern, what follows if it is true, one step a named person can take, and a red or amber severity. Every one cites at least two of the facts it was given and at least one standing statement, with a sentence saying why that statement bears on those facts. Source references are never written by the model: it selects the facts it used, and the platform resolves those selections back to rows it already holds — so an invented row pointer is not something that is checked for but something that cannot be constructed. Every observation is labelled AI-generated per Art. 50 and carries the model id and prompt version that produced it. The pass also emits a running log of its own decisions, which carries stages and counts and never an observation's words.

Human oversight

An observation arrives 'proposed' and nothing auto-confirms. It cannot close a compliance question on its own — it is not reproducible from a stored run the way a rule finding is, so it cannot be evidenced later, and its only two honest destinations are confirmation as a named person's own judgement or dismissal with a reason. Before a person sees one at all it passes the same five gates every observation on the platform passes: it must name what it reasoned from, its references must land on rows that exist, it must not reason from knowledge the user has set aside, it must not restate a check that already fired on the same rows, and it must say what to do. It is additionally refused if it states any figure, date, part number, lot, heat or percentage that was not in the material actually sent.

Training & data

Third-party foundation model (Anthropic Claude, accessed over API from the DefenceOS engine, never from the browser). The derived facts are supplied as data for that one pass and are not used to train the foundation model.

Limitations

• **A pack whose documents are all above the ceiling produces nothing at all.** A bill of materials is EU-controlled by the platform's own interface catalogue whatever the uploader declares, so the documents carrying the most supply-chain risk are frequently the ones this system may not be shown — and the joins that involve them cannot be made this way. The running log names each refused document rather than going quiet, but the cost is real and is not recoverable by rewording the request.
• It reasons over what the checks established, not over the documents. Where a check read a value wrongly, or where a risk appears in a document nothing checked, this system inherits the gap.
• Non-determinism. Two passes over the same pack can propose different observations, differently worded. The rule findings, their severities and the rows they cite do not vary, and are produced before this pass runs.
• It can be confidently wrong about a relationship. Two documents naming the same lot identifier may be the same lot or two lots with one identifier space, and this system cannot tell without a source the platform does not hold.
• Where the model is unconfigured, egress is disabled on the build, the engine is unreachable, the account has no credit or the reply is refused by validation, no observation is made and the deterministic findings stand unchanged. This is the ordinary case, not an error state, and the running log says which of them happened.

Answers the question a person asks after reading a finding: where did this come from. It walks backwards from the finding through the other documents in the pack to the thing that caused it — a Union-content shortfall on a declaration, because of a re-sourced line on a bill, because of a sub-tier change, evidenced on a certificate that had already lapsed — and then proposes what to do about the cause, which is a different question from what to do about the finding. Each move in the walk is a separate claim resting on a separate row, so a reader who rejects the third move has rejected everything upstream of it without having to argue about the conclusion.

Inputs

• The finding being traced, in the platform's own words, and — where a published rule authored the remedy — that remedy, sent so the model adds to it rather than rewording it. The platform's general fallback step and any earlier model proposal are deliberately NOT sent as “what the rule prescribes”, because neither is.
• Derived facts about the pack: what each published check concluded, each permitted row as it was read, each table's shape and each document's shape.
• Three separate context layers. The platform's standing knowledge about defence supply chains, minus any statement the user has set aside — a set-aside statement cannot be cited, and a chain citing one is refused rather than filtered. The company's own stated priorities, verbatim. And what the last analysis actually examined: how many rule versions ran, over how many rows, and how many bindings could not be checked at all — that last figure being what separates “the chain ends here because this is where it started” from “the chain ends here because this is where our coverage ran out”.
• **Nothing whatsoever derived from a document classified above the hosted-inference ceiling, and nothing at all for a finding raised on one.** The finding's own label is the stronger of the two gates: a finding on an EU-controlled bill is not traced even where the rest of the pack is unclassified, because the question being asked quotes the controlled material. The decision is taken in the engine, before a prompt exists.
• Never sent: the documents themselves, filenames, row identifiers, the rule run's internal id, or the company identity.

Output

An ordered chain of between two and six links, each one sentence and each citing exactly one row of one document; a statement of the cause in supply-chain terms; the standing knowledge the chain applied, with a sentence per statement saying why it bears on these particular documents; and — in a separate field the model has no way to write into — the remedy the published rule already prescribes, echoed unchanged. Alongside it, and clearly apart from it, the model's own conclusion about what to do about the cause: one step, an owner, a window and a sentence naming which link of the chain it answers. The response also names every document type the classification ceiling refused, so a chain with a hole in it is rendered as one. Source references are never written by the model — it selects the facts it used and the platform resolves those selections back to rows it already holds, so an invented row pointer is not something checked for but something that cannot be constructed. Every model-authored part is labelled AI-generated per Art. 50 and carries the model id and prompt version that produced it.

Human oversight

Nothing here decides anything and nothing here executes. The finding stays 'proposed', its severity is unchanged, and the remedy the rule prescribed is echoed back untouched — the two remedies are two fields of two different types on the response and are rendered under two separate headings, so a reader can tell a rule's instruction from a model's inference before reading a word of either. The panel is given no callback that could change a finding's status. The trace runs only when a person presses for it; nothing is sent on opening the finding. Before a chain is shown at all it must pass six gates: it must be at least two links, every link must cite a row that was actually sent, no two consecutive links may rest on the same row, it must name at least one standing statement it reasoned from, it must contain no markup, and it must state no figure it was never given.

Training & data

Third-party foundation model (Anthropic Claude, accessed over API from the DefenceOS engine, never from the browser). The pack's derived facts are supplied as data for that one trace and are not used to train the foundation model.

Limitations

• **The model never calculates.** Percentages, shortfalls and totals are the platform's, computed deterministically before any model is asked anything; the model reasons about them. This is enforced rather than requested — a figure it worked out for itself is a run of digits it was never sent, and the chain carrying it is refused whole. The consequence is that the trace can only reason about arithmetic somebody already did.
• **A chain across a controlled document cannot be drawn.** A bill of materials is EU-controlled by the platform's own interface catalogue whatever the uploader declares, and on an origin-evidence pack the bill is exactly where the cause usually lives. So the ordinary honest outcome is a chain that cannot cross the middle of its own story. The panel names each refused document rather than presenting the severed chain as a complete one, but the missing step has to be taken in the enclave or by hand and is not recoverable by rewording the request.
• It can be confidently wrong about a relationship. Two documents naming the same part or lot may be the same thing or two things sharing an identifier space, and this system cannot tell without a source the platform does not hold. The chain is shown as a walk precisely so that a wrong link can be rejected on its own.
• Non-determinism. Two traces of the same finding can produce differently worded chains and different remedies. The finding, its severity, the rows it cites and the remedy its rule prescribed do not vary, and all of them exist before this runs.
• It reasons over what the checks established and what the permitted documents say. Where a value was read wrongly, the chain will walk back through the wrong value confidently.
• Where the model is unconfigured, egress is disabled on the build, the engine is unreachable, the account has no credit or the reply is refused by validation, no chain is produced and the finding, its owner and its remedy are exactly as they were. This is the ordinary case, not an error state, and the panel says which of them happened.

Answers questions about one finding — what it means, what the underlying rows say, and what the options are — while the user decides how to rule on it.

Inputs

• The finding under discussion, the rows it cites, and the company context for that set.
• The user's question.
• No other finding, no other set, and no other organisation's data.

Output

Plain-language answers, labelled as AI-generated per Art. 50. Advisory only — the answer carries no decision and changes nothing on the record.

Human oversight

Read-only by construction, not by instruction: the panel is given no means of changing data, findings or context, so there is no path by which a conversation can alter the record even if the model proposed one. The interface states this rather than leaving the user to infer it. Every ruling is still taken through the decision controls, by a named person.

Training & data

Third-party foundation model. The exchange is not used to train the foundation model.

Limitations

• It can discuss one finding. It cannot compare findings, analyse the set as a whole, or reach any other supplier.
• It can restate and explain what the analysis found; it cannot independently verify it against the original document.
• It has no ability to act. Anything it suggests still has to be done by a person.

Reads what you say in the context chat and writes it up into your company context — what you make and for whom, what matters most to you, and the rules you hold suppliers to. That context changes how seriously the analysis ranks a finding.

Inputs

• What you type in the context chat.
• Your existing company context, so a new sentence can be placed against what is already there.
• The platform's own observations about your sets, so an instruction about one of them can be matched to it.
• No document content, and no other organisation's data.

Output

A proposed change to your context, with the exact wording it would add or take out and a plain-language summary of the effect. Labelled as AI-generated per Art. 50. Your context is never written directly — the write-up you read is rendered from the entries you have accepted.

Human oversight

Nothing takes effect until you press Apply. Every accepted change is kept as a revision holding what you actually typed, verbatim, beside what the model made of it — so a write-up can always be traced back to the sentence it came from. The platform's own observations are not written by the model at all; where you disagree with one it is suppressed with your reason kept against it, never removed.

Training & data

Third-party foundation model. What you type in the context chat is not used to train the foundation model.

Limitations

• It classifies a sentence into one of four sections. A sentence that fits none of them is kept as a general note rather than discarded, but it may be filed somewhere you would not have chosen.
• It tidies wording — capitalisation, punctuation, removing conversational openers — and does not rewrite meaning. If a sentence was ambiguous when you typed it, it stays ambiguous.
• It cannot tell whether what you told it is true. Context is your statement about your own business, and the analysis treats it as such.
• Context changes how findings are ranked. It cannot make the analysis check something the published rules do not cover.

Answers questions about one extracted document set — what a certificate says, when it expires, which article it covers — while a reviewer works through the pack.

Inputs

• The canonical record of the one document set named on the scope chip, and the findings raised against it.
• The user's question.
• No other document set, no other supplier, and no other organisation's data.

Output

Answers in one of three registers, each stated as such and each differing in what it is allowed to cite. An answer drawn from the set cites the documents and pages it rests on. A computed answer cites the rule that derived it and says plainly that no document states the figure. A general-knowledge answer is labelled as background knowledge and cites no document at all — the register exists precisely so that what the model knows about a standard is never attributed to a document in the pack. Every answer is labelled AI-generated per Art. 50.

Human oversight

Advisory and read-only. The panel is given no means of changing the canonical record, the findings or the actions, so a conversation cannot alter what is on file. A persistent scope chip names the set every answer is bounded by, so a reader can see the boundary rather than having to trust it. Approval of an extraction remains a human act taken elsewhere; nothing said here approves anything.

Training & data

Third-party foundation model. The exchange is not used to train the foundation model.

Limitations

• It can answer about one document set. It cannot compare sets, reach another supplier, or see anything outside the pack on screen.
• It restates what the extraction holds; it cannot independently verify that against the original scan, and the extraction itself may be wrong.
• A cited page is a pointer into the canonical record, not proof that the record read the page correctly.
• It has no ability to act. Anything it suggests still has to be done by a person.

Answers a person's own questions about a set that has already been analysed — which finding is most urgent and why, who owns the red ones, whether two findings trace to the same document — in plain words rather than by reading the plan. It reasons over the analysis the person is already looking at; it raises no finding, changes no severity, and takes no action.

Inputs

• A compact projection of what is on the Actions screen: each document's filename, declared type and resolved classification; each finding's title, severity, status, one-line concern, the ruleset it was checked against, and its recommended step, owner and window; each action's title, owner and window; and any free-text note the user wrote for this set.
• The user's typed question, and the conversation so far.
• Never sent: raw cell values, the source files themselves, any other document set, or another organisation's data. The projection carries the shape of the result, not the contents of the estate.

Output

A conversational reply grounded in the projection it was given, labelled AI-generated per Art. 50. The reply is text for a person to read; it is not written back to any finding, action or record.

Human oversight

The panel is handed no callback that could change a finding, a cell, an action or the context — the read-only promise is structural, not a matter of the copy or of asking the model to decline. Everything it says is a restatement or interpretation of the analysis a named person still owns; nothing it says takes effect, and the same person still confirms, downgrades or dismisses each finding themselves.

Training & data

Third-party foundation model (Anthropic Claude, accessed over API from the DefenceOS engine, never from the browser). The projection and the conversation are supplied as data for that one exchange and are not used to train the foundation model.

Limitations

• It answers from the projection alone. Where the extraction read a value wrongly, or a finding is itself mistaken, the assistant inherits that error and can restate it confidently.
• It is not a check and cannot close a compliance question. It cannot raise a finding, change a severity, or move an action.
• Non-determinism: the same question can be answered in different words on different occasions.
• It sees one set and the compact projection of it — not the raw tables, not another set, and nothing outside the pack on screen.
• Where the model is unconfigured, egress is disabled, or the engine is unreachable, no reply is produced and the panel says so rather than inventing one.

A specialist mode of the AI Analysis bench that assesses a supplier against the platform's existing risk rules. It is a front door onto the risk engine that already computes and stores risks — it does not compute a second, competing risk score. It fetches the supplier's real risks, explains the most material ones, and narrates the assessment so a person can read it in plain language.

Inputs

• A supplier the user names or resolves from their own portfolio, and the risks the engine has already raised for that supplier (fetched, not computed here).
• The tenant's optional analysis context — sector, priorities, constraints — used to frame the narration, never to invent a risk.
• Optional attached supplier evidence, and the user's question.

Output

A narrated risk assessment in which every risk stated traces to the rule that raised it, shown in a traceability panel beside the answer, and the AI's reasoning steps shown as it works. The narration explains the fetched risks and their mitigations; it does not raise, re-score, or invent a risk. Labelled AI-generated per Art. 50.

Human oversight

Advisory. The mode surfaces what the risk engine already holds and explains it; it takes no action, opens no case, and changes no score. The existing risk-case and Command Centre machinery remains the only place a risk is acted on, by a named person.

Training & data

Third-party foundation model (Anthropic Claude, via the engine) for narration only. The risk data is supplied as data for that one explanation and is not used to train the model.

Limitations

• It reasons over what the risk engine established. Where a rule is wrong or a risk went unraised, the narration inherits that gap — it is not an independent audit.
• It cannot resolve a supplier it cannot find, and says so rather than assessing a guess.
• Non-determinism in the wording. The risks, their severities and the rules behind them come from the engine and do not vary with the narration.
• Where the model is unconfigured or the engine is unreachable, the fetched risks are shown without narration rather than fabricated.

A specialist mode that projects demand forward from the history the tenant uploads. It is the single surface on the platform permitted to state a number that no document holds, because a forecast is by nature a projection of a figure that does not exist yet — and it earns that only by computing the number with a named, inspectable method and by carrying a projection disclaimer on every answer.

Inputs

• The demand history the user attaches — a table of quantity per period — and a horizon.
• The tenant's optional analysis context, used to frame the explanation, never to alter the computed numbers.

Output

A forecast with a confidence band, the method that produced it (an ordinary-least-squares trend with additive seasonality), and a method trace exposing the slope, intercept, residual sigma and seasonal indices — so the projection can be reproduced and checked. **Every forecast carries a disclaimer that it is a projection, not a fact.** The AI narrates the drivers (trend, seasonality) in words; it never authors a number. Labelled AI-generated per Art. 50.

Human oversight

Advisory planning aid. The numbers are computed by the method, not by the model, and are estimates of the future — a person plans against them, they are not treated as measured values or written to any record as fact. The disclaimer is un-dismissable on the answer.

Training & data

The forecast is computed locally by a deterministic statistical method — no model produces the numbers. A third-party foundation model may phrase the driver explanation only; the history is not used to train it.

Limitations

• **This is the one place the platform states a generated number, and it is always a projection, never a fact** — every other analysis on the platform refuses an un-sourced number.
• The method assumes the future resembles the trend and seasonality in the history given. A structural break the history does not contain will not be foreseen.
• Accuracy is bounded by the history supplied: a short or noisy series widens the band, and the band widening with horizon is the honest statement of that uncertainty.
• It forecasts the series it is given; it does not know about a contract, a plant closure or a market shift the tenant did not encode in the data or the context.