The BakeWise Biga Engine — architecture
One engine learns every product in every shop, plans every batch, and files every invoice — from a five-shop obrador to a multi-company group.
Machine scale
Five figures, each one readable in the product or its documentation: one model per product per shop, over sixty declared signals with fifteen to forty kept per model, five Spanish fiscal regimes behind one dispatcher, sensor ingestion built and wired, and zero third-party model APIs in inference.
Five numbers you can read in the repository.
Model sovereignty
No. Demand forecasting is trained and served on our own EU infrastructure with Prophet and an XGBoost model fitted to its residuals, and there is no call to a model vendor anywhere in the request path — nor anywhere else. The egress allow-list is generated from the code, not written by hand.
No third-party model API sits in the inference path.
Demand forecasting is trained and served on our own infrastructure. There is no call to an external model vendor anywhere in the request path, which makes data isolation a property of the architecture rather than a clause in someone else's terms of service.
No dependency on OpenAI, Anthropic, Google or hosted inference in any service of the platform. Forecasting runs on Prophet with an XGBoost model fitted to its residuals, trained and served in-house; document extraction runs on a local OCR engine.
Each customer's forecasts come from models fitted on that customer's own history, per product and per location. Nothing is pooled across tenants and nothing is used to train a shared model.
Training and serving happen on EU infrastructure alongside the data. There is no outbound inference hop, so there is no cross-border transfer to disclose or defend.
Unit economics do not move when a model vendor changes its price list or deprecates a model. Capacity planning is an infrastructure decision, not a procurement negotiation.
This architecture isn't accidentally complex. The platform was built as a generic autonomous operational governance layer — bakery is the first vertical. Horizontal portability (multi-tenant, predictive ML, VRP, company hierarchy, modular compliance) is deliberate and documented in the internal roadmap. Adjacent verticals and geographic expansion are evaluated case by case.
The engine, in four strata
Four strata, bottom to top, in the order the run executes: which signals come in, what the models learn from them, what the agents decide on that, and which legal obligation is closed at the end. It is not a metaphor — each stratum names code, and each names what it refuses to do.
Four strata, one engine.
Bottom to top: which signals come in, what the models learn, what the agents decide, and which legal obligation is closed at the end. The map is not a metaphor — it is the order the run executes in.
Stratum 1 · Data
Every shop is its own time series. Signals are collected per company AND per location, so two shops in the same city never share a pattern.
POS sales, line by line
Sync clients for Square, Lightspeed, Toast, Revo, eposnow and Storyous, plus CSV over SFTP for everything else. Every line arrives with its own tax rate.
Weather per location
AEMET, ERA5 and MET Norway at each shop's coordinates, not the provincial capital.
Calendar and events
National, regional and municipal holidays, school calendars and city events, attributed to the location that actually feels them.
What surrounds the shop
Points of interest detected over OpenStreetMap and Nominatim — offices, schools, stations — turned into features of that location's model.
Obrador, shop and plant sensors
Continuous per-machine telemetry over OPC-UA, MQTT and Modbus, against a published integration contract: a reading is one machine at one instant, and an integration that splits it into pieces gets an explicit rejection instead of losing data silently. HACCP temperature logging, cold-chain incidents and a dedicated ingest ceiling per company.
Laboratory, sensory panel and shelf life
Trials with comparable arms, tasting panels, laboratory results entered by hand or by CSV, and shelf-life studies closed out arm by arm. What product development learns feeds the same engine that plans production.
Stratum 2 · Models
One model per product per shop — and what that model hands over is a calibrated band, not a loose figure. There is no global model your business has to resemble.
One model per product per shop
Training is keyed on company, product and location: Prophet learns the seasonal shape, an XGBoost model learns what Prophet missed, over a registry of sixty-plus declared signals from which each product's model keeps the fifteen to forty that earn their place by sales velocity. Nothing is pooled across customers. A global gradient-boosted quantile model is trained beside them as a challenger: it is measured, and it never serves.
A band, not a number
Every forecast comes out as a calibrated band — q10, median and q90 — never as a single figure. The width is measured when the model is trained: conformal quantiles of its out-of-sample error on a held-out window, stored with the model and applied unchanged at serving. That band is what makes deciding by cost of error possible in the next stratum.
Continuous learning
Real sales flow back into the model: error is measured against what was forecast and retraining is scheduled per product rather than by calendar.
Drift monitoring
When demand moves away from the distribution the model learned, the drift is detected and flagged for retraining instead of degrading quietly.
Learned rules, not hardcoded ones
The effect of rain or heat on each product is estimated from history and only enters the forecast when it clears statistical significance (p < 0.05). There are no hand-written percentages.
Stratum 3 · Agents
Thirteen agents, one pass. Each reads what the previous one left, and none writes without respecting the governance posture of the company it serves.
Data agent
Ingests and cleans sales, stock and external signals before anything is forecast.
Forecast agent
Demand forecast per product and per location over the plan horizon.
Production agent
Turns the forecast into a baking schedule: batches, oven sequence and real capacity.
Workflow agent
Instantiates each batch's workflow with its control points and the competencies it requires.
Workforce agent
Proposes rotas against the forecast production load, shift by shift.
Procurement agent
Proposes supplier orders from the bill of materials, stock on hand and lead times.
Transfers agent
Advisory or enforcedTransfers from the central obrador to each shop, optimised routes, and the fiscal document each movement requires: an internal delivery note within one tax ID, paired or independent invoices when the tax IDs differ.
Network plan agent
Sums the demand of every shop in the network into a single production plan, with per-shop attribution.
Pricing agent
Detects margin compression and proposes a price; in a franchise network it can only recommend.
Insights agent
Writes the business reading that explains why the plan is the plan.
Validation agent
Checks the whole plan for coherence before it reaches a person.
Notification agent
Ranks alerts by business impact, urgency, the user's ability to act, and model confidence.
Sentinel agent
Closes the pass with a per-tax-ID fiscal-integrity check and watches for anomalies.
In a chain or a corporate subsidiary the plan executes. With a franchisee the same agent may only recommend: every child carries four flags — schedules, price, production volume and purchasing — created switched OFF when the relationship is a franchise, and a database constraint stops any non-child row from having them off. The procurement agent emits a suggestion and returns before writing anything. That is RD 201/2010 and the EU vertical block exemption regulation written into the schema, not into a style guide.
An agent's posture is not re-derived inside each agent: one evaluator resolves it with a fixed precedence — law, circuit breaker, the company's policy and, last, what the agent declares. Law outranks everything else: a franchisee is never executed against, whatever a policy says.
Circuit breaker — above any policy
If the model has drifted, the POS data is stale or a signal behaves anomalously, the engine drops to proposing and says why. It sits above the company policy in the precedence, so no checkbox can switch it off.
Autonomy policies per product family
Each family declares its posture — auto, review or signature — and auto only holds while the decision fits inside both declared limits: deviation in percent and impact in euros. An unknown deviation does not approve itself, it falls to review. The evaluator and its limits are written and tested; the screen that edits them per family is being wired.
Stratum 4 · Compliance
Jurisdiction is configuration: compliance is a country pack plugged into a registry, not one country's rules scattered through the product. Spain is the pack live today, Portugal is packaged except for invoicing, and France and Mexico are architected.
| Control | Status | What it means exactly |
|---|---|---|
| Spain — AEAT | In production | No-gap sequential numbering, per-rate VAT (4%, 10%, 21% and exempt), delivery note versus invoice, VeriFactu and SII. It is what Spanish companies on the platform file today. |
| Basque foral territories — TicketBAI | In progress | Built and XAdES-signing against the foral schema, with foral homologation in progress. We do not call it live until it is. |
| Portugal — pack 0.1.0 | In progress | Geography, holidays, tax identity and rates are packaged. Invoicing is deliberately not: issuing an invoice in Portugal fails closed with a named reason instead of improvising a format we have not validated. |
| France · Mexico | Architected, not shipped | Architected, no code: the jurisdiction chain (EU → country → territory) and the per-domain interfaces were validated on paper against NF525 and CFDI. Adding either means writing a pack, not rewriting the product. |
Mechanisms
Four claims on this page are not policy documents: they are constraints the code enforces. A trade arrives as a declared pack. The circuit breaker outranks every policy. A franchisee cannot grant itself authority over master data. And one jurisdiction is in production while the rest are named as architecture.
Agent Orchestration
One pass, thirteen agents, each reading what the previous one left behind: sales and signals, forecast, production schedule, purchase orders, stock, delivery routes and the business reading. Each behaves as a state machine — collect, analyse, recommend, wait — so the run is deterministic and every step is auditable afterwards.
How the Agents Work Together
Each agent specializes in one domain but collaborates with others through a shared data layer and event-driven communication.
The Intelligence Flow
Data flows from sales and external sources through forecasting, which drives procurement, production scheduling, inventory management, and logistics — while strategy analyzes the big picture and sentinel monitors for anomalies.
Each agent operates as a state machine: collecting data, analyzing patterns, generating recommendations, and waiting for human approval before executing. This ensures deterministic behavior and full auditability.
Platform Architecture
By row-level isolation the request cannot argue with: company headers are stripped from every incoming request and re-injected from the verified token, each domain owns its own isolated database on encrypted disks, and there are no cross-service foreign keys. Authorisation is three local gates on the token and zero upstream calls.
Built for Scale and Resilience
Domain-isolated services on high-availability EU infrastructure, built for multi-company baking operations with enterprise-grade controls.
Row-based isolation with company-scoped headers, stripped from the incoming request and re-injected from the verified token. No cross-service foreign keys. Each domain owns its own isolated database on encrypted disks — one service cannot read another one’s tables, and no company can reach another company’s rows.
The token carries the tenant, the role, the department and the permission bitmap, so the gateway makes zero upstream calls on the request path. Three gates run locally on every request: signature and token-type policy, revocation, and claim freshness. A revoked session is refused even if the token has not expired.
SAML 2.0 single sign-on against your identity provider, and user joiners and leavers synchronised over SCIM 2.0 from your directory. Who works with you is decided by your HR system; we obey it and log it.
Parent-child tenants with materialized-path queries, so a subtree read never needs a recursive query. A parent reading into a federated child's operational data is gated on an explicit authorisation on that child — the role alone never grants it, and switching into a child does not carry any cross-network capability with it.
The platform runs across several independent machines in an EU data centre instead of one server, with the database layer replicated across them. Orchestration is self-healing: when a machine is lost, the work it was carrying is rescheduled automatically.
Infrastructure and application alike are declared in code. Every change is versioned, reviewed before it applies and auditable afterwards; nothing is edited by hand on a running machine, so the state of the platform is always something you can read, compare and roll back.
Subscription middleware enforces plan limits at the gateway from the URL shape itself, so no service can define its way around them. Two levels: Chain and Group, with the industrial vertical riding the Group level.
Connectors
With a read-only service account your team creates and can revoke, or an agent that only makes outbound connections so your firewall stays shut. Every line that arrives keeps its source, its external identifier and when it last changed there. For that data we are a processor, under a DPA.
How we read your systems.
For the technical evaluator: exactly what we ask for, what we do not open, and what is recorded about every record that comes in.
A service account with read permissions over sales, purchases, stock and the product master. Created and revocable by your team. Never a person’s credentials.
For on-premise systems, an agent that only makes outbound connections: it extracts using versioned query profiles and uploads over HTTPS. Your firewall stays shut. Alternatives: an SFTP you drop files on, or an outbound tunnel.
Every line that comes in keeps where it came from, under which external identifier, and when it last changed at source. Reprocessable and auditable.
For the data coming from your systems we are a processor: a DPA per customer, minimisation by default in the extraction profiles, EU hosting, and per-company deletion on request.
Security & Compliance
Nine controls, each one a duty someone would otherwise close by hand: HACCP logging and traceability, GDPR as a processor, per-jurisdiction fiscal records, a human approval before execution, a hash-chained audit trail, EU residency, continuity across machines, encryption in transit and at rest, and off-site backups with a written restore path.
Trust at Every Level
Built from the ground up for per-jurisdiction regulatory requirements — one pack per country, with Spain live first.
Certification status
None yet. ISO/IEC 27001 is in progress, SOC 2 has not been started and no independent penetration test has been performed. What exists is stated row by row below: EU residency, a data-processing agreement, corporate single sign-on, a hash-chained audit trail verified nightly, and the rows that are still in progress.
What we hold, and what we don't.
This table exists so nobody has to go looking. A certification we do not hold is stated here, on its own row, rather than in a footnote.
| Control | Status | What it means exactly |
|---|---|---|
| EU data residency | In production | Processing and storage in EU data centres, on infrastructure we operate ourselves. No outbound inference hop. |
| GDPR — data processor | In production | A DPA per customer, minimisation by default in the extraction profiles, and per-company deletion on request. |
| Corporate identity (SSO and provisioning) | In production | SAML 2.0 single sign-on and automatic user provisioning and deprovisioning over SCIM 2.0, available on Group. Identity responses are validated on signature, recipient, audience and time window, and are never accepted twice. |
| Hash-chained audit trail | In production | Every CREATE, UPDATE, DELETE and EXPORT is chained by a hash covering the whole record, and an automated job walks the chain every night, recomputing each record and alerting if a link fails to add up. Integrity is verified on the chain, not on the exported file. |
| High availability | In production | The platform runs across several independent machines with a replicated database layer, and orchestration reschedules work automatically when one of them is lost. |
| Backups and restore drills | In progress | Backups are automatic and held off-site, and every store has a documented restore procedure. Scheduled restore drills are not yet running; we will move this row to live the day the first one is timed and recorded. |
| Spanish fiscal obligation | In progress | VeriFactu and SII in production. TicketBAI built and XAdES-signing, with foral homologation in progress. |
| ISO/IEC 27001:2022 | In progress | We are implementing an information security management system. Its scope, policy, risk assessment and a Statement of Applicability covering all 93 Annex A controls are drafted and await management approval. We do not hold the certification and have not engaged a certification body. |
| SOC 2 | Not achieved | Not started. No date committed. |
30-minute technical conversation with the people building the engine. NDA before the first call on request.
Open the same engine on a live bakery
Request conversation