Demonstrations
See the system at work.
From raw input to human approval and structured output. You start the run, you follow each step, and you decide whether the action goes ahead.
Demonstration on synthetic data. The pipeline, rules and validation actually run; only the data is fictitious. No real company or client data is represented.
Parsing, consistency checks, gap detection, business rules and logging actually run in your browser. The steps marked AI rely on a language model in production; here they are replayed from a recorded result, with no network call and no cost.
Division of roles
What AI does, and what it does not.
The most costly mistake is entrusting a calculation to a language model. In a serious system, each layer does what it is good at.
AI Interpret
- Understanding free text
- Classify a request
- Extracting fields from an unstructured document
- Finding documents by semantic similarity
- Rephrasing, summarising
Code Calculate and apply
- Prices, discounts, lead times
- Company business rules
- Consistency and schema checks
- Calls to existing systems
- Logging and traceability
Human Decide
- Anything that commits the company
- Anything irreversible
- Ambiguous cases and exceptions
- Deciding when confidence is low
- Responsibility, which cannot be delegated
Under the hood
The architecture, step by step.
Click a block to see what it actually does, and what happens when it fails.
Input
The trigger: an e-mail, a dropped file, a form, a webhook, a time of day.
- The raw message is kept as is, so that processing can be replayed.
- Attachments are isolated before anything is read.
- If the input is unreadable, it goes to a human queue rather than being guessed.
Parsing
Turning raw input into something usable: decoding, text extraction, OCR if the document is scanned.
- A fully deterministic step: same input, same output.
- A corrupted PDF fails here, cleanly, without polluting what follows.
- Useful metadata (sender, date, size) is kept.
Classification and extraction
This is where a language model adds something: reading freely written text and turning it into structured data.
- Each extracted field carries a confidence score.
- A missing field stays missing: the system does not fill gaps.
- Below a confidence threshold, the case is passed to a human.
Context retrieval
Finding, in your own documents, what sheds light on the request: comparable files, client history, applicable procedure.
- Every retrieved item cites its source.
- Access rights also apply to search.
- Nothing is invented: if nothing matches, the answer is “nothing found”.
Business rules
Prices, lead times, thresholds, routing. Everything that must be exact lives here, in readable, testable code — never in a model.
- A wrong rule can be read and corrected in one line.
- Calculations are reproducible and auditable.
- This is where your company’s specific requirements are encoded.
Human approval
The checkpoint, placed just before the irreversible or externally visible action.
- The proposal is shown next to its source, on the same screen.
- Uncertain points are flagged so that attention goes to the right place.
- Approval, modification and rejection are all logged.
Action
Writing to your systems: creating a file, preparing a quote, opening a ticket, sending a reply.
- Each tool receives only the permissions it needs for its task.
- A failed action can be replayed without creating duplicates.
- No sensitive action without approval at the previous step.
Logging
Who did what, when, on which data, with what result.
- Essential in the event of an audit or dispute.
- Makes it possible to measure the exception rate and improve the rules.
- An automation that fails silently is worse than a forgotten task.
Guardrails
What keeps the system from going off track.
An agent given a tool receives real power. These constraints are not optional.
- No binding action without explicit human approval
- Data schemas checked on input and on output
- Permissions limited per tool, to the strict minimum
- End-to-end timestamped logging
- Confidence thresholds: below the threshold, a human decides
- A missing field stays missing, never guessed
- Deterministic rules wherever they are sufficient
- Human fallback when a step fails
What an AI must not decide alone
- A legal decision
- A payment or financial commitment
- A permanent deletion
- A critical business approval
- A contractual communication to a client
- Any decision where an error would be invisible and irreversible
Frequently asked question
Why not just ChatGPT?
A very good tool, and often the right starting point. But a conversational assistant used on its own, without dedicated integration, answers a question; it does not take charge of a process. What follows compares two ways of using AI, not two products.
A conversational assistant used on its own
- Waits to be asked
- Only has the context provided in the conversation
- Produces an answer: a human then has to transfer it into the systems
- Context has to be provided again in each new session
- The result depends on how the request is worded
- The history stays in the tool, not in your business records
A system connected to your workflows
- Triggered by an event: e-mail, file, form, webhook
- Retrieves context from your documents and databases
- Applies your business rules in deterministic code, not through generation
- Prepares the action and submits it for human approval
- Writes to the ERP, CRM or e-mail through dedicated integrations
- Logs every step, timestamped and sourced
Conversational platforms now offer connectors and APIs: the difference is not “impossible” versus “possible”, but a generic tool versus a system built for a specific process, with its own rules, controls and traceability.
Before / after
What changes in the working day.
Today
- The e-mail arrives
- Open the attachment
- Copy the data by hand
- Find the client file
- Open the ERP
- Re-enter
- Reply
With automation
- The e-mail arrives
- The system prepares everything
- You approve
The checking does not disappear. The data entry does.
Use cases
The most common flows.
Each one follows the same mechanism: unstructured input, extraction, context, rules, validation, action.
Document processing
Documents arrive unsorted, in different formats depending on the sender.
- Workflow
- Sorting, extraction, completeness check
- Approval
- Before any accounting entry
- Systems
- DMS, ERP, accounting
E-mail sorting and routing
A shared mailbox receives invoices, support, sales and urgent matters all mixed together.
- Workflow
- Category, priority, client, recipient
- Approval
- On outgoing replies
- Systems
- E-mail, CRM, ticketing
Requests for quotation
Each request arrives with a drawing, a material, tolerances, sometimes a spreadsheet.
- Workflow
- Extraction, comparison with history, preliminary costing
- Approval
- Before sending to the client
- Systems
- ERP, CRM, document management
Client files
A complete file requires several documents, rarely all received the first time.
- Workflow
- Completeness check, chasing missing documents
- Approval
- Before a decision on the file
- Systems
- DMS, CRM
Document search
The information exists, but nobody knows which file it is in.
- Workflow
- Indexing, semantic search, sourced answer
- Approval
- Sources cited, verifiable
- Systems
- Internal document base
Incidents and call-outs
Reports arrive via portal, e-mail and phone, with no common format.
- Workflow
- Qualification, urgency, assignment, routing
- Approval
- On costly call-outs
- Systems
- Ticketing, facility management
Configurator
What would your flow look like?
Four questions, one indicative architecture. This is not a quote — just the shape the system would take.
Your potential flow
Discuss this workflow →Technical evidence
Public code, not a brochure.
Technical demonstrations published on GitHub. These are demonstrations, not client projects.
Tests
What we try to break before you do.
The happy path always works in a demonstration. What matters is everything else.
- Required data missing
- Third-party system unavailable
- Duplicate received twice
- Unreadable or corrupted document
- Extraction confidence too low
- Unexpected format
- User without the required permissions
- Timeout exceeded
Measurement
What a production system should measure.
No performance figures are shown here: we do not publish results we have not measured at a client.
Processing time
From receipt to result, by request type.
Exception rate
Share of cases escalated to a human, and why.
Correction rate
How often changes are made at the approval stage.
Volume
What actually passes through the flow, day after day.
Cost per item processed
Model calls and infrastructure, per unit.
Availability
And above all: silent failures, detected.
Case studies
Client case studies will follow, with the clients’ consent.
We do not publish invented cases or unmeasured results. Each case study will follow the same structure, so that you can compare what matters.
- 01
Context and challenge: the company, the process, what the problem was.
- 02
Existing environment: the tools, the data, the constraints.
- 03
Solution and architecture: what was built, and why.
- 04
Controls: human approvals, security, traceability.
- 05
Deployment and results: go-live and measured results.
Approach
From demonstration to your system.
Process
We look at how things really work in your company, not how they are supposed to work.
Prototype
We build a limited flow, on a single process, with your real cases.
Approval
We run it in parallel with manual processing and compare.
Production
We connect your tools, monitor, and fix what reality reveals.
Do you have a similar process?
Describe what you do today, step by step. It is the best starting point — far more useful than a specification.