how it works

From your expert’s head to a workflow that runs.

No implementation project. No data science team. Annona connects to what you already have, captures how your best operator actually works, proves it on your own history, and then runs it, with your people approving every action.

getting connected

3 steps. One clear picture.

STEP 01

Connect your data

Link your ERP, WMS, or operational data source, read-only. No migration, no transformation, no waiting.

  • Connects in minutes, not months
  • No data duplication required
  • Works with existing exports if needed
STEP 02

Annona detects what matters

It analyses your operational patterns and surfaces the signals most likely to become problems, before they do.

  • Early signals, not lagging indicators
  • Explainable. No black-box outputs
  • Tuned to your operational context
STEP 03

You get a clear recommendation

What’s happening, why it matters, and what to do next, with the downstream actions already drafted.

  • Situation → Impact → Action format
  • Every recommendation is traceable
  • Delivered where your team works
annona discovery

A 4-step interview, not a 6-month consulting build.

The moat isn’t the report. It’s the method. Discovery converts tacit expert knowledge into a spec that runs, in 4 structured steps with your domain expert.

01

Show the output

Your expert shows the finished artefact they produce today: the report, workbook, or decision.

02

Show the inputs

The systems and data they actually consult, and how the domain objects relate to each other.

03

Walk one real example

Step by step through a real past case: the rules they follow, the judgement calls, the edge cases.

04

Review & correct

Annona plays its understanding back; the expert corrects it. Then exception harvest and test cases.

the artefact

The 11-field workflow spec.

One artefact, three consumers: Discovery captures it, the engine executes it, the product renders it. Below, each field is shown with the real worked instance from our pilot: the supply-availability diagnostic behind SB-4420-K.

01
OutcomeThe finished result the workflow produces, plus a real example artefact
Executive summary + operational workbook stating buildable / not buildable, root blocker, orders at risk, recommended action. Example: the SB-4420-K report.
02
Trigger / cadenceWhat kicks it off: scheduled, on-demand, or event-driven
On-demand per item; scheduled daily for the top backordered lines.
03
SourcesThe systems and data read, and the access method
ERP (read-only API): item master, aggregate item-location, BOM, work orders, sales orders. Connector: NetSuite REST.
04
EntitiesThe domain objects and how they relate
Assembly → Level-1 sub-assembly → Level-2 raw material; Work Order; Sales Order; Customer; Supplier.
05
RulesThe deterministic steps and thresholds: the ordered diagnostic sequence
Confirm item → check finished goods → walk L1 components → identify short or committed component → trace incoming supply → link to customer orders → recurse deep BOM → isolate root blocker.
06
JudgementsWhere the expert applies judgement, and the heuristic they actually use
Is “available” stock truly usable now vs reserved? Is an incoming work order reliable, or flagged? Which shortage has the highest commercial impact?
07
ExceptionsKnown edge cases, the 20% that isn't the happy path
Incoming supply flagged on-hold (the false-fix trap); obsolete component still on an active BOM (data error, not shortage); packaging and service lines excluded from shortage logic.
08
Human responsibilitiesThe approval points and human-in-the-loop gates
Planner approves the recommended decision; account owner approves customer ETAs before send.
09
ActionsWhat the workflow emits: drafted comms and tasks, and who approves before send
Draft expedite request (internal), revised-ETA email (customer, lead-time-aware), monitor / ticket / log (system). Nothing sends without approval.
10
Test casesHistorical instances the spec must reproduce to be trusted: the Validation Gate
Re-run the last N shortage events; the spec must name the same root blocker the expert did.
11
Success metricsHow the customer knows it is working
Time-to-root-cause, % of delayed orders with a defined action, backorder aging.
the validation gate

A spec isn’t done until it reproduces your expert’s real decisions.

Before any workflow goes live, we replay it against your expert’s real past cases. It must name the same root blockers they did, to a stated pass rate, before a single live commitment.

  • Historical replay against real past shortage events
  • Target pass rate agreed up front (e.g. ≥90% of cases reproduced)
  • The hallucination defence: trust is proven, not claimed
validation · historical replay
WorkflowSupply-availability diagnostic
Test setLast N shortage events, expert-labelled
Pass ruleSame root blocker the expert named
Gateno live run until the gate passes
under the hood

The spec compiles to 2 functions.

diagnose() returns the reasoning trace, verdict and outputs. act() returns the drafted actions. Exceptions, approval gates and test cases govern the guardrails. That’s the whole product surface, which is why it’s auditable.

diagnose(item)

Runs the ordered diagnostic sequence from the spec against live data: reasoning trace → verdict → executive summary + operational workbook → recommended decision.

act(item, decision)

On your approval: system tasks complete automatically; comms to internal teams, suppliers and customers are drafted with rationale and queued for one-click human send.

Watch it run →
see it on your data

Bring us your gnarliest workflow.

If your best operator can walk us through it in an afternoon, we can spec it, validate it on your history, and show it running on your data.