Baptiste BouaultTechnical dossier, 2026 FR Français

Baptiste Bouault, AI engineer and CTO of a B2B AI startup

sheets, including 5 systems in production or in pilot with clients

See the sheets
Title
Baptiste BouaultAI engineer, CTO of a B2B AI startup
Subject
AI agents in production with clients: phone, audit, purchasing. The model proposes, the code decides.
Scale
1 dot = 1 versioned commit
Contact
Email
Cannes
--:--
Lisbon
--:--
  1. April : Consulting engagement: analytics for a national retail network
  2. May : Merger arbitrage, personal project
  3. July 1 : CTO of an AI startup
  4. August 6 : Platform for gyms: first commit
  5. September 30 : Platform pilot installed

Parts list

Sheets

Seventeen systems, each with its diagram, analysis and limitations. A row marked with a reference opens its sheet.

The dots on the cover page are the 1,839 commits versioned in 2026 across 35 repositories: a trace of activity, not a measure of the work. Part of it happens on the production machines, outside these repositories.

  1. AI startup, CTO role9 parts

    1. S1Voice receptionistsVoice agents that book, cancel and transfer, for five clients.In productionLate June to October 2026
    2. S2Platform for gymsMulti-tenant platform; isolation enforced by the database and broken on purpose.PilotAugust to September 2026
    3. S3Audit intelligenceStandards agent that cites standards down to the paragraph, for an audit firm.In productionJuly to September 2026
    4. S4Audit working papersSelection of third parties for confirmation, acceptance-tested on real audit files.DeliveredLate July to August 2026
    5. S5Restaurant purchasingFrom chefs' messages to orders; invoices read twice.PilotJuly to October 2026
    6. S6Guardrails for coding agentsSecurity review by agents; gatekeeper closed by default.PrototypeAugust to October 2026
    7. S7Operations control planeSupervision of agents in production, specified.SpecificationJuly to September 2026
    8. S8Technical exercise with a hidden graderGrader with hidden tests, proven red then green.DeliveredSeptember 2026
    9. S9A website where every fact has its sourceCompany website where a fact without a source erases its block.BuiltAugust to October 2026
  2. Consulting, Ascend Partners7 parts

    1. C1Local analytics platformAnalysis and simulation of a store network; the model computes nothing.DeliveredApril to June 2026
    2. C2GEO AuditWhat generative engines answer, without prompting them with the brand.DeliveredMay to June 2026
    3. C3Audit of a legacy scoring engineA VBA engine reproduced to the hundredth before looking for the cause.Delivered2026
    4. C4Presentation pipelineConsultant notes into presentations; brand guidelines kept separate from the rules.PrototypeMay 2026
    5. C5Research agents for a teamAgents and skills for a consulting team; orchestration redesigned.DeliveredMarch to May 2026
    6. 15Social media monitoringWeekly monitoring for the marketing team of a consulting client: local video transcription, editorial briefs.
    7. 16Resilience assessment toolAssessment calculator for the firm's website: scoring engine and tests.
  3. Personal and freelance projects11 parts

    1. P1Compliance pre-reviewPre-review of marketing materials, evaluated against ground truth.PrototypeSeptember 2026
    2. P2Marine dealer websiteInventory updated from a PDF spec sheet; dependency-free reader.In productionAugust to September 2026
    3. P3Merger arbitrageReading public tender offers in three jurisdictions; stopped by what it measured.PrototypeMay to June 2026
    4. 20Cinq. websiteWebsite for the freelance business, static page.
    5. 21This portfolioThis dossier: a static page generated by script, in French and English.
    6. 22Guided tour booking websiteBilingual, dependency-free website, online payment, every amount recomputed server-side. 26 tests.
    7. 233D wound-healing simulatorPrototype: parametric model drawn from the literature, its constraints written as tests.
    8. 24Prospecting pipelineSourcing from public data and enrichment; nothing sent without human review. 205 tests.
    9. 25Workout appPersonal workout tracking: magic-link sign-in, row-level isolation. Prototype.
    10. 26Trading botsPersonal bots: the third version was stopped after measuring a negative expected value, fees included.
    11. 27Other personal toolsListings aggregator, contact verification.

In the field

Clients

Each client, anonymized: what was delivered, where it stands, and what the deployment taught.

Names stay with the clients. Statuses are dated; a system that is not running yet is labeled as such.

  1. Sports club, two sitesVoice receptionist that books and cancels in the client's software; a platform meant to replace it

    Voice in production since June 2026; platform in pilot since September 30

    The model got long notice periods wrong: the decision moved to code.

    S1S2

  2. IT resellerVoice switchboard: transfers and messages

    In service since July 2026

    Transfers are real: a test call rings real people.

    S1

  3. Auction houseVoice assistant built to a "zero invention" spec

    Go-live targeted for mid-October 2026

    A newer model invented a date: the model is chosen against the spec.

    S1

  4. RestaurantTakeout orders by phone

    In service

    A summer closure has to be scheduled: switchover prepared in advance, executed on August 2.

    S1

  5. Auto parts distributorVoice switchboard

    In service

    A reply in a foreign voice: each client's languages are now pinned.

    S1

  6. Statutory audit firmStandards agent and time-entry fixes

    In production

    A missing year dated hours a year too early: every date goes through a plausibility window.

    S3

  7. Member firm of an international networkSelecting third parties to confirm

    Pilot run in July and August 2026

    The only accepted judge: matching the selection the auditor made by hand.

    S4

  8. Multi-site restaurant groupChefs' orders, invoice reading

    Pilot

    The costly errors are the date, the preview and the total.

    S5

  9. National retail networkLocal analytics and simulation; measuring presence in generative engines

    Delivered in June 2026

    An indefensible figure is not displayed, even with a caveat.

    C1C2

  10. A large institutionAudit of a legacy scoring engine

    Delivered in 2026

    Reproduce to the hundredth before concluding.

    C3

  11. Industrial group and mutual insurance groupMulti-agent benchmarks, audit of a scoring grid

    Delivered in spring 2026

    Agents do not orchestrate each other in a cascade: the main session launches them.

    C5

  12. Boat dealer, family businessWebsite, inventory updated from a PDF spec sheet

    In production since August 17, 2026

    The launch-day audit found flaws in the site itself.

    P2

  13. US broker-dealer, hackathonCompliance pre-review of marketing materials

    Prototype, September 2026

    A corpus written by the author of the rules remains a regression bench.

    P1

General notes

Notes

Valid for all sheets. Each note is illustrated at least once in a diagram.

  1. 1

    The model proposes, the code decides: notice periods, capacity, caps and amounts are computed by code.

  2. 2

    No confirmation is given until the action has been executed and read back.

  3. 3

    Isolation is proven by breaking it on purpose: an injected regression must make the test suite fail.

  4. 4

    Any action that touches production waits for an explicit green light that names it, every time.

  5. 5

    A displayed figure carries its source and its measurement method; without a source, it disappears, including here.

  6. 6

    Guardrails are attacked by their author: every bypass found becomes a test before its fix.

Delivery loop

Every delivery follows the same loop: a dated specification, execution, a machine proof, then an explicit green light before production.

Example, sheet S3: on July 17, hours entered without a year are dated a year too early. The guardrails are written with their rollback plan, proven in tests, in production on July 20; the log that would have recounted the incident arrives on the 21st.

Revisions

Background

Consulting, a first startup co-founded then dissolved, now CTO of a B2B AI startup, between Cannes and Lisbon.

The first startup's user count is the company's own figure; it has no repository to consult.

Rev.DateSubject
EJul 2026B2B AI startupCTO and AI engineer, since July 2026Sole engineer on the team: voice agents in production and business platforms for audit, fitness and restaurants.
DJan 2026Ascend PartnersAI and data consultant, January to July 2026Final-year internship: engagements for large corporate clients, analysis and agent tools.
C2026ESSECGlobal BBA, graduated in 2026Specialization in data and AI.
B2025UC BerkeleyExchange semester
A2025RhinovateCo-founder and COO of a first startupHealthtech company that went through Founders Inc in San Francisco. 2,500 paying users in three months. Company dissolved in 2026.
Location plan
LisbonCannes
  • Agents

    Real-time voice agents, multi-agent systems with human validation, evaluation against ground truth, guardrails for coding agents.

  • Engineering

    Python, FastAPI; PostgreSQL and row-level security; TypeScript, React, Next.js; telephony and voice; DuckDB, multi-agent simulation.

  • Consulting

    AI solution benchmarks, committee presentations, scenario modeling, measuring presence in generative engines.

Let's talk.

baptiste.bouault@gmail.com

S1

Voice receptionists

Voice agents that answer calls, identify the caller, book or cancel in the client's software, and transfer the call or take a message. One engine lineage, adapted client by client.

In production. At a sports club since early June 2026, on an IT reseller's switchboard since July, then at other clients.

Sheet
S1
Status
In production
Type
Client product
Period
Late June to October 2026
Role
Took over the voice portfolio in late June 2026: guardrails, production fixes, measurements, new deployments. The first engine predates my arrival.
Context
AI startup, CTO role
Stack
Python, FastAPI, WebSocket, real-time telephony, speech recognition and synthesis, tool-using model
History
Startup repositories under a shared team identity; some of the fixes are written directly on the production machines.
Last revision
Sep 11, 2026
Distribution
Public, hatched areas retained

DiagramTiming diagram of a call

How to read Time runs from left to right. Each lane is a component; a diamond is a decision made by the code. The agent starts speaking only after the write has been read back.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

On the phone, every sentence commits the client and the slightest stall is audible. The model understood the requests well, but it got the arithmetic of lead times wrong: it read the session time correctly, then announced a cancellation as free when it would be charged.

The second risk was mechanical: one blocking I/O operation on the speech path is enough to freeze the audio stream, and the caller no longer hears anything.

Decisions

  1. ChosenThe notice-period verdict is formulated by the code; the model relays it without recomputing.

    RejectedPutting the timestamp back at the top of the instructions. Tried, then removed.

    WhyAcross 180 samples, the model was wrong 8 times out of 8 beyond 8 h of notice and 0 times out of 8 at 2 h: the error only appears at long lead times, and it had to be measured to be seen.

  2. ChosenEvery I/O operation in the conversation turn runs off the event loop.

    RejectedKeeping synchronous calls, which are simpler to read.

    WhyA synchronous call on the loop starves the audio stream and cuts off transcription. Measured offline: a 645 ms freeze when a call opens before the fix, 29 ms after.

  3. ChosenFor the auction house, the standard model.

    RejectedA newer model, then a lightweight model.

    WhyThe newer one invented a date; the lightweight one failed 13 of the 16 checks in the specification.

What broke

  1. July 10

    A false cancellation confirmation was spoken in production. Three silent paths were still open; they were closed on August 6, and since then nothing is confirmed before the write has been read back.

  2. July 12

    Cascade of silences in production, up to about 21 seconds: a blocking read was freezing the event loop. All I/O in the conversation turn was moved out of the loop.

Limits to date

  • One repository per client: a fix is still carried over by hand from one repository to another.
  • In mid-July, not all refusal paths had been tested on real calls; they are still monitored in the log.
  • No call volumes published: those figures belong to the clients.
  • Git does not separate my work from the CEO's: the commits share a team identity.

In the field

ClientWhat runsDated status
Sports club, two sitesBookings and cancellations written to its booking software, then read back; a late cancellation goes to the team as an alert.In production since early June 2026
IT resellerSwitchboard: transfers to the right person, and messages; invoice lookup is waiting on the client.In service since July 2026
Auction house"Zero invention" specification: the assistant never appraises a piece and transfers as soon as information is missing.Transfers activated on September 11; go-live targeted for mid-October
RestaurantTakeout orders by phone; summer closure scheduled, then switched over.In service; switchover executed on August 2, 2026
Auto parts distributorSame engine lineage; organization languages pinned after a reply in a foreign voice.In service

Dimensionsmeasurements and counts, with how they were measured

645 → 29 msevent loop freeze when a call opens, before and after the fix. The "before" is reproduced on a bench with eight simulated 80 ms reads.measured offline
8 / 8errors when the model itself stated a notice period of more than 8 h; 0 out of 8 at 2 h. 180 samples in total.measured offline
21 sorder of magnitude of the longest silence in the July 12 incident, before the fixdocumented by the project

Revisions

FSep 11, 2026Transfers activated for the auction house
EAug 10, 2026"Zero invention" specification for the auction house
DAug 6, 2026No more confirmations before the write is read back
CJul 12, 2026Cascade of silences: I/O moved out of the loop
BJul 10, 2026False cancellation confirmation in production
AJun 22, 2026Voice portfolio taken over

Parts listcomponents

  1. 01Real-time telephonyanswers, streams audio both ways
  2. 02Transcriptionfollows the call's language; switches on explicit request
  3. 03Tool-using modelunderstands the intent and proposes an action
  4. 04Rules in codenotice period, actual capacity, member's unit
  5. 05Bridge to the client's softwareguarded write, then read back
  6. 06Language guardthe reply comes out in the call's language
  7. 07Speech synthesisspeaks once the action is executed
  8. 08Model instructionsretained content
  9. 09Business thresholdsretained content

Notes

  1. The model proposes, the code decides: notice period, capacity and unit are computed by the code.
  2. No confirmation is spoken before the write has been executed and read back.
  3. Missing information: the call is transferred or a message is taken.
  4. Restarting, changing the instructions or the configuration in production requires an explicit go-ahead, every time.

Hatched areas

What this sheet does not show, and will not show:

  • Instructions and examples given to the model
  • Notice thresholds and rules for each client
  • Callers' names, numbers and data
  • Integration with the client's software
  • Call volumes

What this shows

Measure where the model gets it wrong, then take the decision away from it.

Next sheet, S2Platform for gyms

S2

Platform for gyms

Back office, API, member and coach app, training program engine: a multi-tenant platform for a two-site sports club. Isolation between tenants is enforced by the database, and proven by breaking it on purpose.

Pilot. Installed on September 30, 2026, on real data, read-only. The legacy software remains the source of truth; no cutover date has been set.

Sheet
S2
Status
Pilot
Type
Client platform
Period
August to September 2026
Role
CTO: architecture, isolation, pilot delivery
Context
AI startup, CTO role
Stack
Python, PostgreSQL and row-level security, 86 migrations, server-rendered app, dependency-free TypeScript program engine
History
Versioned in the startup's repositories.
Last revision
Sep 30, 2026
Distribution
Public, hatched areas retained

DiagramIsolation floor plan

How to read Plan view. The hatched walls are the database access policies: a tenant sees only its own room. The corridor is the API; the log only receives appends.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Replacing a client's live booking software without ever writing the same truth twice, even though that software returns its failures with a success code.

And maintaining isolation between tenants that the database can silently bypass: the first suite passed its 44 assertions on a database that was leaking.

Decisions

  1. ChosenIsolation is enforced by the database, with migrations run under the owner role.

    RejectedA superuser that switches roles, then a regular-expression guard.

    WhyThe role switch was dropped at the first "commit"; the pattern guard was bypassed in five ways during the counter-audit.

  2. ChosenDual writes are refused by triggers that check the resulting state.

    RejectedLeaving the rule to the import code.

    WhyThree updates bypassed a trigger set on insert only.

  3. ChosenThe AI layer is installed but switched off, with a cap per tenant.

    RejectedThe 24 AI capabilities proposed at the outset.

    Why18 were dropped for lack of product need.

What broke

  1. August 6

    The first audit found 8 flaws in the isolation, then 8 more in the fixes themselves.

  2. August 25

    Six probes out of nine read another tenant by changing the identifier in the URL. Fixed before any go-live.

  3. September 8

    Two out of three injected regressions went unnoticed: the fake test server was too permissive, and about 1,200 green tests had caught nothing. The suite was hardened.

  4. September 29

    A member could modify another member's booking. Fixed the day before installation.

Limits to date

  • No cutover date: the platform does not replace the legacy software yet.
  • The apps run on a demo organization; the voice agent's call to the API is simulated.
  • An email integration has never been tested against a real response; two known test failures remain open.
  • The program engine has 67 values to calibrate, not yet reviewed by a strength and conditioning coach.

In the field

ClientWhat runsDated status
Sports club, two sitesReal platform, read-only, alongside the legacy softwarePilot installed on September 30, 2026
Fictitious gymsProgram enginePrototype from September 9, 2026

Dimensionsmeasurements and counts, with how they were measured

78 / 78regressions deliberately injected into the isolation, all detected, as of September 8measured offline
261 / 261cross-tenant isolation assertions, up from 18 to 50, then 261measured offline
3,872back-office and API tests as of September 30, with 2 known failures still openmeasured offline
2,571member and coach app testsmeasured offline
455program engine tests, run reported on September 9measured offline
57 / 648sessions generated outside the time budget, on the fictitious gymsmeasured offline

Revisions

FSep 30, 2026Pilot installed, read-only
ESep 29, 2026App audit: cross-member access fixed
DSep 9, 2026Program engine prototype
CSep 8, 2026Isolation suite hardened: 78 regressions injected, 78 detected
BAug 26, 2026First demo, on fictitious data
AAug 6, 2026First back-office commit, first isolation audit

Parts listcomponents

  1. 01Isolation by the databaseeach tenant sees only its own rows, enforced by the database itself
  2. 02APIreasoned refusals, idempotency, append-only log
  3. 03Legacy mirrorread-only, the legacy software remains the reference
  4. 04AI layeroff by default, budget per tenant
  5. 05Human approvalan outgoing message with no approver cannot be written
  6. 06Member and coach appno local business logic
  7. 07Program enginesame input, same program; works without AI
  8. 08Schema and rulesretained content

Notes

  1. Isolation is enforced by the database and proven by injected regressions.
  2. An outgoing message drafted by the model cannot be written without a human approver.
  3. The engine works without AI; AI breaks ties between equivalent exercises and writes the instructions.

Hatched areas

What this sheet does not show, and will not show:

  • Data schema and access policies
  • Business rules and wellness rules
  • Client name, units and figures
  • Replaced third-party software

What this shows

Refuse a green test that was never red: the isolation suite was broken on purpose from day one.

Next sheet, S3Audit intelligence

S3

Audit intelligence

A platform for a statutory audit firm: portfolio, agent-based time entry, due diligence. I added a standards agent that triages work programs, citing the standards down to the paragraph.

In production. Platform in service since June 2026, launched by the startup's CEO; partners on restricted access since July 9. Individual accounts planned for October.

Sheet
S3
Status
In production
Type
Client platform
Period
July to September 2026
Role
Standards agent module (corpus, triage, citations) and production fixes to time entry
Context
AI startup, CTO role
Stack
Python, FastAPI, SQLite full-text search, PDF extraction, fuzzy matching
History
Startup repository; the standards module is developed on the production machine dedicated to the client and is not version-controlled.
Last revision
Sep 18, 2026
Distribution
Public, hatched areas retained

DiagramGraduated rules

How to read At the top, the entry calendar: the hatched area is outside the plausibility window, and the gauge is the day's total. At the bottom, the corpus: each arc links a procedure to the cited paragraph.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

On July 17, billable hours entered without a year ("on 14/07") were dated a year too early. Invisible in the monthly check, they were found only through the server logs.

On the standards side, a wrong citation costs more than no answer: an auditor must be able to open the cited paragraph.

Decisions

  1. ChosenA plausibility window, the single gate for reconfirming dates.

    RejectedRequiring the year to match the audited fiscal year.

    WhyAn entry made in January for December is legitimate; the simple rule would have blocked correct entries.

  2. ChosenAn append-only log that also records failures.

    RejectedA log of successful writes only.

    WhyOn July 17, it would have been empty: it was the failures that told the story of the incident.

  3. ChosenThe displayed balance sheet follows the audit software's grouping.

    RejectedA net total computed by the platform.

    WhyThe total was off from the filed balance sheet by several hundred thousand euros; elsewhere, a balance sheet that was right to the cent was right only by coincidence.

What broke

  1. July 17

    Phantom hours dated a year too early, and the same line deleted 18 times in one second. Guardrails in production on July 20, the log on the 21st, with a written rollback plan.

  2. July 20

    Without a file that the initial plan had left out, idempotency would have gone inert again on restart, even with the test suite green.

  3. July 23

    No server-side cap and no library pagination: 1,430 results displayed as 60. Both fixed.

Limits to date

  • Individual accounts not yet in place: the standards agent will open to other users after that.
  • Citations are checked during triage and work suggestion; a free-form question does not go through this check.
  • The standards module is not version-controlled, and the repository's security debt is known and tracked.

In the field

ClientWhat runsDated status
Statutory audit firmThe firm's platform, standards module, agent-based time entryIn production; partners on restricted access since July 2026

Dimensionsmeasurements and counts, with how they were measured

137corpus documents, standards and procedures, split into about 6,112 segmentsdocumented by the project
7partners with restricted scope on July 9documented by the project
1,430matches that a library search displayed as 60, before the July 23 paginationdocumented by the project
108platform routes, excluding the standards modulecounted in the repository

Revisions

FSep 18, 2026Presentation to the whole firm
EJul 23, 2026Server cap and pagination fixed
DJul 20, 2026Entry guardrails in production
CJul 17, 2026Incident: phantom hours
BJul 15, 2026Standards module: corpus, triage, work suggestion
AJul 9, 2026Partners on restricted access

Parts listcomponents

  1. 01Firm's client registrythe firm's portfolio is authoritative
  2. 02Time-entry agentextraction, fuzzy matching, confirmation card
  3. 03Pure rulesdaily cap, plausibility window, missing year
  4. 04Append-only logenforced by the database; a failure is recorded without breaking the request
  5. 05Standards corpusfull-text search, paragraph-level reference
  6. 06Citation checkany reference not in the corpus is removed and recorded
  7. 07Thresholds and instructionsretained content

Notes

  1. Only the confirmation writes; replayed, it writes only once.
  2. A citation exists only if its paragraph exists in the corpus.
  3. After two balance sheets that did not match, the view reproduces the audit software's grouping.

Hatched areas

What this sheet does not show, and will not show:

  • Firm, staff and audited entities
  • Model instructions and thresholds
  • Third-party software and its data
  • Real balance sheets and amounts

What this shows

Turning an incident in auditors' data into computed rules and an immutable log, deployed with a rollback plan.

Next sheet, S4Audit working papers

S4

Audit working papers

For a second firm, a member of an international network: reproducing its method for selecting third parties to confirm, on its own audit files, with no synthetic data and without writing to its audit software.

Delivered. Pilot phase run from July 28 to August 3, 2026, with 11 green acceptance cases on real audit files. The startup's CEO extended it afterwards; it was still active at the end of September.

Sheet
S4
Status
Delivered
Type
Client platform
Period
Late July to August 2026
Role
Steering the pilot phase in batches, selection engines, acceptance on real audit files
Context
AI startup, CTO role
Stack
Python, FastAPI, SQLite, pandas, trial balance readers, strict typing
History
Code in the startup's repository since August 10; the pilot's commits were lost in the import.
Last revision
Aug 3, 2026
Distribution
Public, hatched areas retained

DiagramSampling line

How to read Third-party accounts are laid end to end, each as long as its balance. Letters mark the criteria; vertical lines mark the monetary-unit sampling interval on the rest.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Reproducing a firm's method, stackable criteria and monetary-unit sampling, across six different trial balance formats. The specification only arrived with the extraction of the audit files.

The only judge allowed: matching, on real audit files, the selection the auditor had made by hand.

Decisions

  1. ChosenIndependent criteria: one entity can carry several marks.

    RejectedA sequential order, where a selected entity leaves the population.

    WhyA single reason per entity did not match the firm's working papers.

  2. ChosenOpening balances compared by class and account by account.

    RejectedComparison by class only.

    WhyThe class total hides reclassifications between accounts.

  3. ChosenTotals computed on the entire population, with an independent cross-check.

    RejectedThe total of the first hundred accounts, displayed as the total.

    WhyPart of the balance was missing; the cross-check showed it.

What broke

  1. July 31

    The provisional order coded overnight is contradicted by the real working papers: engine rewritten the same day.

  2. Questionnaire and letter template missing from the shared folder: pre-filling and letters not done during the pilot.

  3. August 4

    Fixes made on the machine only; the pilot's commits were lost in the August 10 import.

Limits to date

  • One criterion is copied from the auditor's working paper; another is checked by membership in the residual, without a strict recomputation.
  • One exception awaits a human decision.
  • Acceptance tests are skipped without the real data: they only run in the client's environment.
  • The confirmation letters were added after the pilot, by the startup's CEO.

In the field

ClientWhat runsDated status
Member firm of an international networkThird-party selection pilot, then an extension by the startup's CEOPilot run from July 28 to August 3, 2026; active at the end of September
Third firmOne-day prototype on the pilot's architecture, by the startup's CEONot deployed

Dimensionsmeasurements and counts, with how they were measured

11 / 11green acceptance cases on real audit files on July 31: 3 forms, 7 populations, 1 full chainmeasured offline
3confirmation forms reproduced identicallymeasured offline
0difference by class in the opening balances of the two audit files tested; one reclassification found at account levelmeasured offline
0synthetic data, excluding legal bounds: acceptance on real audit files is authoritativedocumented by the project

Revisions

DAug 3, 2026Code frozen for the demo, end of the pilot
CJul 31, 2026Engine rewritten, 11 green acceptance cases
BJul 29, 2026Acceptance test principle set
AJul 28, 2026Start of the pilot phase, in batches

Parts listcomponents

  1. 01File readingthe firm's audit files, audit software in read-only mode
  2. 02Normalizationan unknown format is refused, never guessed
  3. 03Pure enginestransformations with no I/O, testable on their own
  4. 04Selectionstackable criteria, then monetary-unit sampling on the residual
  5. 05Cross-checktotals recomputed independently on the entire population
  6. 06Firm's criteria gridretained content

Notes

  1. Zero synthetic data: only acceptance on real audit files counts.
  2. The firm's rules are reproduced as they are, including several marks on the same entity.
  3. Without an API key, an exception is raised before any network call.

Hatched areas

What this sheet does not show, and will not show:

  • Firm, network and logo
  • Entities, amounts and screenshots of audit files
  • Selection criteria grid

What this shows

Steering an agent in batches until it reproduced a firm's real working papers; the architecture laid down during the pilot was reused for another firm.

Next sheet, S5Restaurant purchasing

S5

Restaurant purchasing

Chefs' messages become orders, and supplier invoices are read so they can be reconciled. A human approves before anything is sent.

Pilot. Order capture and invoice reading in use since summer 2026 at a multi-site restaurant group. Accounting posting is not in service yet.

Sheet
S5
Status
Pilot
Type
Client platform
Period
July to October 2026
Role
Reliability work on amounts, dates and sends; the interface is mostly written by the startup's CEO
Context
AI startup, CTO role
Stack
Next.js, React, TypeScript for the interface; separate reading and reconciliation service
History
Interface version-controlled in a startup repository; the service is hosted on a startup machine.
Last revision
Sep 29, 2026
Distribution
Public, hatched areas retained

DiagramThree-column reconciliation

How to read In flow order: the chef's message, the structured order, the invoice read twice. Below, the total keeps the state of each amount.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Chefs write in free text, with size grades that are easy to mix up. On invoices, the printed name is not always that of the legal issuer.

The costly errors are specific: an order sent twice, an invented amount, a delivery dated for the wrong day.

Decisions

  1. ChosenSending is done by reference: the server rebuilds the text, and the preview is exactly what goes out.

    RejectedSending the text shown on screen.

    WhyA gap between the preview and what is sent is invisible to the person approving.

  2. ChosenThe delivery date is computed in the restaurant's time zone.

    RejectedThe time zone of the machine or the browser.

    WhyOn a machine set to UTC, an order placed between midnight and one in the morning was dated the day before.

  3. ChosenA stateful total: confirmed, estimated, partial or unpriced.

    RejectedThe raw sum of the lines.

    WhyA partially priced order showed a total of €0.08.

  4. ChosenThe supplier is identified by the tax ID read from the invoice's QR code.

    RejectedThe printed name.

    WhyThe printed name is not always the legal issuer.

What broke

  1. August 10

    An invisible character in pasted text made an item search fail: the search now opens pre-filled and cleaned.

  2. The 2 GB machine went down under load: calls go through in batches of three.

  3. A document triage screen is enabled, then suspended: its suggestions were wrong.

  4. September 29

    The "€0.08" total of a partially priced order is replaced by the stateful total.

Limits to date

  • Writing to the ERP is not in service: the integration stays inactive on the main branch.
  • Actual sending to suppliers was only proposed in mid-August; it is not proven here.
  • Demo access, and no automated tests in the interface.

In the field

ClientWhat runsDated status
Multi-site restaurant groupCapture of chefs' orders; invoice reading; reconciliation preparedOrders in use since July 2026; accounting posting not active

Dimensionsmeasurements and counts, with how they were measured

6order tracking stages, from received to closedcounted in the repository
2independent reads per invoice, compared line by linedocumented by the project
1send attempt per click; a manual resend goes through a confirmationcounted in the repository

Revisions

DSep 29, 2026Stateful total merged
CAug 13, 2026Pilot status: ERP writes blocked by a license
BAug 5, 2026Sending in test mode
AJul 2026Order capture in use

Parts listcomponents

  1. 01Message readingfree text to order lines
  2. 02Pricingper supplier; prices known or marked as estimated
  3. 03Sendingby reference; one attempt per click, named refusals
  4. 04Invoice readingtwo independent reads, compared
  5. 05Reconciliationorder against invoice, line by line
  6. 06ERP and suppliersretained content

Notes

  1. The total invents no amount: confirmed, estimated, partial or unpriced, it says so.
  2. One click, one attempt: no automatic resend, and every refusal is named.
  3. No guessed item goes to a supplier without a human click.

Hatched areas

What this sheet does not show, and will not show:

  • Group, sites, team and suppliers
  • Prices and volumes
  • ERP name and its schema

What this shows

Targeting the costly errors: the date, the preview, the total.

Next sheet, S6Guardrails for coding agents

S6

Guardrails for coding agents

A security review handed to agents, including nine read-only analysts, consolidated by script, with two human gates and a gatekeeper that inspects each command before it runs.

Prototype. Version reviewed on October 1, 2026, after three rounds of adversarial review, before its first real use.

Sheet
S6
Status
Prototype
Type
Internal tool
Period
August to October 2026
Role
Design, then adversarial review of one's own guardrails
Context
AI startup, CTO role
Stack
Python, parsing of the actual shell command, schema-validated JSON outputs, consolidation scripts
History
24 versioned commits, under the team identity.
Last revision
Oct 1, 2026
Distribution
Public, hatched areas retained

DiagramGatekeeper diagram

How to read Piping and instrumentation diagram. The command flows from the agent to the terminal; the gatekeeper valve is closed by default and opens only for an allowed reason. At the bottom, the review line.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

The analyzed repository is hostile data. And a text-pattern deny rule only sees strings: it blocks "git push", not the same command written differently.

So the gatekeeper has to read the actual command, within a bounded time, and never let through what it has not understood.

Decisions

  1. ChosenThe gatekeeper fails closed: any internal error becomes a block.

    RejectedThe tool's default behavior, where a hook error lets the command through.

    WhyA gatekeeper that crashes must not open the door.

  2. ChosenThe gatekeeper is defense in depth; the primary barrier is a disposable copy, with no remote access or credentials.

    RejectedPresenting the gatekeeper as a guarantee.

    WhyIt has known blind spots; the wording that promised more was removed.

  3. ChosenConsolidation and compliance matrix produced by script, verdict "unverified" by default.

    RejectedA matrix filled in by the model.

    WhyA matrix written by a model can claim a check that never took place.

What broke

  1. October 1

    The third version of the gatekeeper let 38 of 42 dangerous commands through: complete rewrite. Each bypass found became a test case before its fix.

  2. A finding from one pass carried over into the next pass, with a risk of leaking between clients: a pass marker confines it.

Limits to date

  • No real pass has been versioned yet: the current version has been reviewed, not proven.
  • Accepted blind spots: parsing timeout, renamed binary, code loaded by an allowed program.
  • For agents that have a terminal, read-only is only requested in their instructions.

Dimensionsmeasurements and counts, with how they were measured

465cases in the gatekeeper test matrix: 323 to block, 142 to let throughcounted in the repository
38 / 42dangerous commands that got through the third versiondocumented by the project
10, 8, 4bypasses found by three successive adversarial reviews, all fixeddocumented by the project
0.3 sworst decision time over 5,500 random commands, measured on the fourth versiondocumented by the project
131deny rules in the configuration templatecounted in the repository

Revisions

COct 1, 2026Gatekeeper rewritten, three adversarial reviews, version reviewed
BAug 11, 2026End of the initial pass
AAug 10, 2026First fleet of analysts

Parts listcomponents

  1. 01Phase 0barriers before any analysis
  2. 02Nine analystsread-only, schema-validated JSON output
  3. 03Three agents that writetests, fixes, report; under the human gates
  4. 04Consolidationby script, without a model
  5. 05Gates A and Btwo human approvals
  6. 06Gatekeeperbefore each command, closed by default
  7. 07Gatekeeper rulesretained content

Notes

  1. Any internal gatekeeper error becomes a block.
  2. What is technically enforced is kept separate from what is only asked of the model.
  3. The gatekeeper is never presented as a guarantee.

Hatched areas

What this sheet does not show, and will not show:

  • Gatekeeper rules and patterns
  • Analyzed repositories and their flaws
  • Test fixtures

What this shows

Attacking one's own guardrails: each bypass found becomes a test before its fix.

Next sheet, S7Operations control plane

S7

Operations control plane

The supervision planned for agents in production: health checks without a model, client feedback turned into tickets, fixes by a confined agent, deployment on double human confirmation.

Specification. Specification dated July 27, 2026. Phase 0 done, phase 1 blocked on access rights; no supervision code has been written yet.

Sheet
S7
Status
Specification
Type
Specification
Period
July to September 2026
Role
Design
Context
AI startup, CTO role
Stack
Planned: async Python, SQLite, system timers, sessions with no inbound port
History
Versioned specification, 1 commit.
Last revision
Sep 10, 2026
Distribution
Public, hatched areas retained

Diagram24-hour dial

How to read One turn of the dial is one day. The 288 ticks on the ring are the health checks, one every 5 minutes. Inside, the life of a ticket. Behavior specified, not implemented.

Behavior specified, not implemented. Reconstruction with fictitious data.

Analysis

What the sheet does not say by itself

The real problem

A single engineer for about ten products, whose instructions are edited outside the repository by several people: the discrepancy between the machine, the repository and the active instructions was invisible.

The specification follows the July 12 silence incident; it aims to catch it before the caller does.

Decisions

  1. ChosenPermissions are carried by a machine tag.

    RejectedA list of machines written into the code.

    WhyConnecting a machine must touch neither the code nor the permissions.

  2. ChosenThe fixer agent runs without credentials; the supervisor does the push.

    RejectedNot documented.

    WhyA confined agent must not be able to publish anything on its own.

  3. ChosenHealth checks without a model; digest in a single call.

    RejectedAn agentic session for the daily summary.

    WhyThe cost has to stay on the order of a cent.

  4. ChosenDeployment by fast-forward only.

    RejectedForcing a machine that has diverged.

    WhyA divergence is a discrepancy to resolve, not to overwrite.

What broke

  1. July 26

    A secret found hardcoded in a client product, moved out of the code; its rotation is left to a human because the value had circulated in plain text.

  2. July

    Multi-line pastes broke in remote sessions: replaced by one-line scripts.

Limits to date

  • Nothing is implemented: phase 1 is waiting for access rights.
  • Branch protections are set but inert on the current plan: the first gate is not technically enforced.
  • The specification covers a single region, while some production machines run elsewhere.

Dimensionsmeasurements and counts, with how they were measured

5 minhealth check interval, without a modelspecification
07:00time of the daily digestspecification
40 turns, 3 USDfixer agent's cap per ticketspecification
10 minvalidity of a deployment confirmation; same activity window checked before restarting a voice receptionistspecification
1active fix per repositoryspecification

Revisions

BSep 10, 2026Phase 0 done, phase 1 blocked
AJul 27, 2026Specification, secrets audit

Parts listcomponents

  1. 01Tagged machinesadded with a tag and a registry line
  2. 02Supervisorno inbound rules at all
  3. 03Healthchecks without a model
  4. 04Triageclient feedback as strict JSON
  5. 05Fixer agentconfined, capped in turns and cost
  6. 06Double gatepull request merge, then exact confirmation
  7. 07Products and machinesretained content

Notes

  1. Adding a machine: a tag and a registry line.
  2. A merge is a first green light; the exact confirmation is a second one.
  3. A diverged machine is refused.

Hatched areas

What this sheet does not show, and will not show:

  • Client products and machine identifiers
  • Accounts and permissions

What this shows

Establishing least privilege before the code: permissions tag, agent without credentials, double confirmation.

Next sheet, S8Technical exercise with a hidden grader

S8

Technical exercise with a hidden grader

A fictitious API with four tickets and a grader with hidden tests. The designed defect does not show from the surface: the sync replies "ok" after importing only part of the entries.

Delivered. Delivered on September 21, 2026: red proof on the delivered code, then green ticket by ticket with the reference fixes. A candidate's attempt is not documented here.

Sheet
S8
Status
Delivered
Type
Technical exercise
Period
September 2026
Role
Design of the exercise and the grader
Context
AI startup, CTO role
Stack
Python, FastAPI, SQLite full-text search, pytest, paginated upstream with injectable faults
History
2 versioned commits.
Last revision
Sep 21, 2026
Distribution
Public, hatched areas retained

DiagramStrip and grading grid

How to read At the top, the 137 upstream entries, in pages of 25: the sync stops at page 3 and replies "ok". At the bottom, each cell is a hidden case, ticket by ticket: filled for acceptance, outlined for regression.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

The delivered code passes its 43 visible tests, while the sync replies "ok" with 50 of 137 entries imported. This called for hidden tests that do not depend on the mock provided to the candidate.

And for proof, ticket by ticket, that these tests tell correct code from wrong code.

Decisions

  1. ChosenThe hidden tests embed their own implementation of the upstream contract.

    RejectedRelying on the mock shipped with the exercise.

    WhyModifying the mock must neither help nor penalize the candidate.

  2. ChosenA progressive proof in five runs: each reference fix turns its ticket green, the others stay red.

    RejectedNot documented.

    WhyIsolating each ticket shows that each test targets its own defect.

  3. ChosenThe red test is committed on its own, and each pull request describes the cause, the fix, the proof and the use of AI, then is defended orally.

    RejectedNot documented.

    WhyThe candidate answers for every line they submit.

What broke

  1. September 21

    No incident; the installation was rechecked on a reinstalled machine, as the previous one was no longer clean.

Limits to date

  • No candidate attempt documented: only the main branch exists.
  • Hidden tests never run on Linux.
  • The secret-scanning tool is optional: without it, the criterion passes marked "unverified".

Dimensionsmeasurements and counts, with how they were measured

53hidden cases: 46 acceptance and 7 regression, split 16, 13, 12 and 12 per ticketcounted in the repository
0 / 46acceptance cases passed by the delivered code; the 7 regression cases passmeasured offline
43 / 43visible tests green on the delivered code: the defect does not show from the surfacemeasured offline
50 / 137entries imported by the sync that replies "ok", fault injected on page 3specification
63 / 63visible tests green after the reference fixesmeasured offline

Revisions

DSep 21, 2026Grader versioned
CSep 21, 2026Green proof, ticket by ticket
BSep 21, 2026Red proof on the delivered code
ASep 21, 2026Exercise versioned

Parts listcomponents

  1. 01Fictitious APIcase files, time tracking, search, upstream sync
  2. 02Paginated upstream25 entries per page, injectable faults
  3. 03Hidden testsindependent of the candidate's mock
  4. 04Manifestthe grader fails if a hidden test in the kit is missing or changed
  5. 05Secrets checkpatterns and environment files always checked
  6. 06Reference solutionsretained content

Notes

  1. The expected behavior is proven before it is asked for: red, then green.
  2. A hidden test that is missing or changed makes grading fail.
  3. The candidate describes their use of AI in each pull request.

Hatched areas

What this sheet does not show, and will not show:

  • Solutions and hidden tests
  • Candidate identities

What this shows

Proving the expected behavior before asking for it, and requiring transparency about the use of AI.

Next sheet, S9A website where every fact has its source

S9

A website where every fact has its source

The company website, static, with no cookies or third-party scripts. Every fact displayed comes from a registry that requires a source; a null fact erases its block at build time.

Built. Redesign merged in early October 2026: fact registry, security headers, build checks. Go-live not verified to date.

Sheet
S9
Status
Built
Type
Company website
Period
August to October 2026
Role
Redesign, fact registry, build checks
Context
AI startup, CTO role
Stack
Static site generator, strict security policy, checks in continuous integration, automated screenshots
History
35 commits, 25 of them under my name.
Last revision
Oct 2, 2026
Distribution
Public, hatched areas retained

DiagramLine drawing with callouts

How to read The page as a line drawing, and the fact registry. Each block points, through a numbered marker, to a line in the registry. A fact without a source erases its block and the page closes up.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

For a company that sells compliance, the site had to apply the same proof rule as production, while the messaging itself was still evolving.

The inventory of the old site counted 94 claims, all to be tied to a source before staying online.

Decisions

  1. ChosenEach fact is a value plus a source; a null fact erases its block.

    RejectedLeaving an empty template or a placeholder.

    WhyAn empty block still displays a promise.

  2. Chosen"Unsourced" is a state distinct from "false".

    RejectedLabeling as false anything missing from a public directory.

    WhyA directory can lag behind reality.

  3. ChosenStatic site with no inline script, strict security policy.

    RejectedAn application rendered in the browser.

    WhyThe page must be readable without JavaScript.

What broke

  1. August 31

    The first measurement of words readable without JavaScript was wrong; redone and corrected in the review file.

  2. August 31

    The registry missed an ongoing pilot in the restaurant sector: a false negative, corrected when the sector came back to the fore.

Limits to date

  • Go-live not verified: it depends on an unmerged branch.
  • No script checks the validity of sources: it is judged in review.
  • The security policy still tolerates inline styles.

Dimensionsmeasurements and counts, with how they were measured

94claims found on the old site and entered in the registrydocumented by the project
8 → 422words readable without JavaScript on the home page, measured on August 31measured offline
17 / 17compliant contrast pairs, computed from the theme colors and checked in continuous integrationmeasured offline

Revisions

COct 2, 2026Messaging updated by management
BOct 1, 2026Redesign merged, contrasts checked
AAug 31, 2026Old site inventory, fact registry

Parts listcomponents

  1. 01Fact registryeach fact: a value, a source
  2. 02Static site generatorno inline script
  3. 03Build rulea null fact hides its block, with no placeholder
  4. 04Security headersstrict policy, inline styles still tolerated
  5. 05Artifact checksin continuous integration
  6. 06Animated demosfictitious data only

Notes

  1. Source or removal, enforced by the build.
  2. "Unsourced" and "false" are two distinct states.
  3. A demo case is never presented as in production.

Hatched areas

What this sheet does not show, and will not show:

  • Subdomains and client screenshots
  • Deployment files

What this shows

Making the proof rule mechanical, and logging the measurement errors of one's own pipeline.

Next sheet, C1Local analytics platform

C1

Local analytics platform

For a national retail network: upload a 2.6 GB sales file and get the network analysis, 36-month simulations and written interpretations. The figures are computed by deterministic engines; the model only puts them into words.

Delivered. Pilot validated in six stores on June 9, 2026; national version delivered on June 26 with figures marked indicative, not validated. Use after delivery is not documented.

Sheet
C1
Status
Delivered
Type
Consulting engagement
Period
April to June 2026
Role
End-to-end design and development, from ingestion to interface
Context
Consulting, Ascend Partners
Stack
Python, DuckDB, pandas, Mesa multi-agent simulation, FastAPI, React, TypeScript
History
Versioned in the engagement's repositories.
Last revision
Jun 26, 2026
Distribution
Public, hatched areas retained

DiagramReplication fan

How to read Each thin line is one replication of the 36-month simulation; the bold line is the mean. Depending on the scenario, the second panel shows the convergence of the mean, the interval on the difference between two scenarios or the check on an answer. Fictitious data.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

The sales file weighed 2.6 GB and a critical column arrived 84% empty; the headline figure depended on exactly that column.

And a written interpretation can state a correct figure for the wrong scope: during testing, an answer about one store gave the value for the whole network.

Decisions

  1. ChosenThe headline figure stays blocked as long as the product range column has less than 90% coverage; the range is never guessed.

    RejectedImputing the missing values.

    WhyMeasuring the gap let the client rebuild the column at the source.

  2. ChosenThe confidence interval is computed on the paired difference, replication by replication.

    RejectedAdding up the margins of the two scenarios.

    WhyAdding them inflated the interval by an order of magnitude.

  3. ChosenEach interpretation goes through a PASS, WARN or FAIL check; on failure, two attempts at most, then a deterministic text.

    RejectedRetrying until a PASS comes back.

    WhyLatency, and a retry loop eventually passes by chance.

  4. ChosenKeeping the figure defensible.

    RejectedTuning the formula toward the hoped-for figure.

    WhyThe figure had to hold up in front of an executive committee.

What broke

  1. April 13

    A scenario difference 28 times too large, then a three-year target read as annual: formulas recalibrated.

  2. May 6

    Independent recomputation of 30 presented figures: 22 matching and 6 failing on the first pass, then 30 out of 30.

  3. May 7

    An external audit finds inverted signs in three scenarios; corrected.

  4. June

    A national value served under a center's label: granularity guard added.

Limits to date

  • National figures are delivered as indicative, not validated.
  • More than half of the regional groupings fall outside a 10% margin: display is capped at the level the statistics certify.
  • The elasticities used have no verified academic reference.
  • Writing the interpretations calls a model; without it, the deterministic text takes over.

In the field

ClientWhat runsDated status
National retail network, pilotSix stores, about 80,000 rowsPilot validated on June 9, 2026
National retail network, national scale2.6 GB file, out-of-core ingestionDelivered on June 26, 2026, indicative figures

Dimensionsmeasurements and counts, with how they were measured

2.6 GBsales file ingested in 5.3 s, with a peak memory of 3.2 GBmeasured offline
27 → 2 minfull simulation at 10 replications, after inverting the sampling; results reproduced to the centmeasured offline
40replications from which the mean stabilizes; the interval is still narrowing at 160measured offline
30 / 30presented figures recomputed independently, matching after correctionmeasured offline
2,000customer agents in the reference configurationcounted in the repository

Revisions

EJun 26, 2026National version delivered
DJun 9, 2026Pilot validated in six stores
CMay 7, 2026External audit: signs corrected
BMay 6, 2026Independent recomputation of presented figures
AApr 13, 2026Scenario differences recalibrated

Parts listcomponents

  1. 01Out-of-core ingestionstreaming read from disk, 22-column schema contract
  2. 02Deterministic engineseach figure computed and frozen before display
  3. 03Multi-agent simulation36 months, replications, interval on the paired difference
  4. 04PASS, WARN, FAIL checkon every written interpretation
  5. 05Granularity guarda figure does not change scope
  6. 06Client data and constantsretained content

Notes

  1. The model formulates; it never computes.
  2. A displayed figure maps to a computed, frozen field.
  3. A missing value blocks the figure that depends on it.

Hatched areas

What this sheet does not show, and will not show:

  • Network, brand and stores
  • Sales file and business constants
  • Client scenarios and results

Sources

  • 2.6 GB in 5.3 scommit message in the engagement repository
  • 30 out of 30repository history
  • 40 replications, 27 → 2 mindocumented constants in the repository
  • 84%repository data dictionary

What this shows

Taking a quantitative decision tool from pilot to national scale, while refusing to display what the statistics do not certify.

Next sheet, C2GEO Audit

C2

GEO Audit

Measuring what generative engines answer when asked about a sector, without prompting them with the brand. One questionnaire, five engines, answers read word for word.

Delivered. First real audit on May 29, 2026, for a national retailer; report validated on June 1.

Sheet
C2
Status
Delivered
Type
Engagement tool
Period
May to June 2026
Role
Design of the measurement and the tool
Context
Consulting, Ascend Partners
Stack
Python, React, per-audit lock, cost tracked per call
History
Versioned.
Last revision
Jun 8, 2026
Distribution
Public, hatched areas retained

DiagramEngine rose

How to read Five branches, one per engine; four rings, one per question category, each split into four questions. Each cell is one combination; detail A unrolls one branch. Fictitious data.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

A brand made of common words turns up inside other words: counting mentions with a plain text search overstates its presence.

Discovery only means something if the question does not contain the brand; otherwise, the engine repeats what it was prompted with.

Decisions

  1. ChosenWhole-word matching.

    RejectedSubstring search.

    WhyA substring match counts mentions that are not mentions.

  2. ChosenNeutral conversations and brand conversations kept separate; neutrality enforced by the server, question regenerated if the brand leaks.

    RejectedLetting the model word the questions freely.

    WhyIt is the condition for discovery to be valid.

  3. ChosenAn ambiguous paste is returned to the operator for splitting.

    RejectedGuessing the split.

    WhyA paste to rework costs less than a silently wrong score.

  4. ChosenAnswers obtained through a developer tool are left out of the score.

    RejectedKeeping them as a proxy for the consumer product.

    WhyThey are not comparable.

What broke

  1. A web search held a channel open and the recommendations kept looping: the entire process tree is now terminated.

  2. May 29

    A storage lock made audits unreadable: reads now return an explicit error.

Limits to date

  • Engine answers are pasted in by the operator: the measurement is semi-manual.
  • One answer per combination: an engine's variance from one run to the next is not measured.
  • Counting and written analysis give different levels on the same audit: the score depends on the reading method.

In the field

ClientWhat runsDated status
National retail chainFour categories, four questions, five engines: 80 combinationsReport validated on June 1, 2026

Dimensionsmeasurements and counts, with how they were measured

5 × 4engines and categories in the base questionnairecounted in the repository
80combinations filled in during the first real auditdocumented by the project
58test functionscounted in the repository

Revisions

CJun 8, 2026Questionnaire import from a scoping note
BJun 1, 2026Report validated
AMay 29, 2026First real audit

Parts listcomponents

  1. 01Questionnaireawareness, sector discovery, purchase intent, values and alternatives
  2. 02Neutral conversationswithout the brand, neutrality enforced by the server
  3. 03Reading the answerswhole words; split refused if ambiguous
  4. 04Per-audit lockonly one process writes an audit
  5. 05Cost trackingper call
  6. 06Client answers and scoresretained content

Notes

  1. The discovery question never contains the brand.
  2. An ambiguous split is returned to the operator.
  3. A non-comparable answer is left out of the score.

Hatched areas

What this sheet does not show, and will not show:

  • Retailer and competitors
  • Engine answers and scores

Sources

  • 80 combinationsaudit file in the repository
  • 58 test functionsrepository count
  • Datesrepository history

What this shows

Designing a measurement for a new subject, with written measurement safeguards.

Next sheet, C3Audit of a legacy scoring engine

C3

Audit of a legacy scoring engine

Resilience scores had dropped on several assets with no explanation. Before looking for the cause, reproduce the three successive versions of the scoring engine, written in VBA, to the hundredth.

Delivered. Consulting engagement carried out in 2026 for a large institution. The code stayed with the client: the figures on this sheet are declared, with no repository to consult.

Sheet
C3
Status
Delivered
Type
Consulting engagement
Period
2026
Role
Reconstruction of the engines in Python, test suite, readout
Context
Consulting, Ascend Partners
Stack
Python, test suite, VBA code reading
History
No repository to consult: the work stayed with the client.
Distribution
Public, hatched areas retained

DiagramResidual plot

How to read Each column is a fictitious asset; each marker is the deviation between the rebuilt score and the original score at one pass. The band is the maximum allowed deviation, one hundredth. Successive passes bring the points back into the band.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Explaining a drop in scores while the calculation method itself was disputed internally. Until the drop was reproduced, any explanation remained an opinion.

Decisions

  1. ChosenRebuilding the three successive engines until every score matches to the hundredth, and only then looking for the cause.

    RejectedLooking for the cause directly in the legacy code.

    WhyWithout exact reproduction, a cause that is found cannot be proven.

  2. ChosenA test suite that locks in each deviation.

    RejectedNot documented.

    WhyEach hypothesis about the cause becomes testable.

Result

Cause found: a rescoring of answers by coefficient, combined with a switch to the geometric mean at pillar level. Reported back with a governance note to align the teams on the method.

What broke

  1. No documented incident.

Limits to date

  • No repository to consult: the sheet rests on the engagement readout.
  • The decision the client made afterward is not documented here.

In the field

ClientWhat runsDated status
A large institutionReconstruction and audit of a scoring engineEngagement delivered in 2026

Dimensionsmeasurements and counts, with how they were measured

3successive versions of the legacy engine, rebuiltdeclared, no repository to consult
0.01maximum allowed deviation between a rebuilt score and the original scoredeclared, no repository to consult
304tests in the verification suitedeclared, no repository to consult

Parts listcomponents

  1. 01Legacy enginethree successive versions, in VBA
  2. 02Reconstructionone Python engine per version
  3. 03Test suiteeach score compared to the hundredth
  4. 04Client data and weightingsretained content

Notes

  1. Reproduce first, then conclude.
  2. An unexplained deviation remains an open deviation.

Hatched areas

What this sheet does not show, and will not show:

  • Client, assets and scores
  • Scoring method and weightings

Sources

  • All figuresengagement readout; declared, the code stayed with the client

What this shows

Settling a method dispute with evidence, by reproducing before concluding.

Next sheet, C4Presentation pipeline

C4

Presentation pipeline

Turning consultants' notes into committee presentations, separating each client's brand guidelines from the composition rules, and without rewriting any of the consultant's words.

Prototype. Designed in May 2026; never tested end to end on a real deck.

Sheet
C4
Status
Prototype
Type
Tool prototype
Period
May 2026
Role
Design
Context
Consulting, Ascend Partners
Stack
HTML composition, rendering to the presentation format, contact sheet, agent skills
History
Versioned, one commit.
Last revision
May 19, 2026
Distribution
Public, hatched areas retained

DiagramPage flow

How to read The extracted brand guidelines, the consultant's note, then the deck's page flow, page by page, as in print production. The numbered markers link each idea in the note to its page. Fictitious data.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Each presentation goes to a client whose brand guidelines must be respected, and the consultant's text must not move: the machine composes; it does not write.

Decisions

  1. ChosenComposition rules coded once; brand guidelines extracted from each client's deck.

    RejectedNot documented.

    WhyThe sorting criterion: if a value changes from one client to another, it goes in the brand guidelines.

  2. ChosenThe consultant's text is never rewritten.

    RejectedRewriting it to improve it.

    WhyThe consultant chooses the wording.

  3. ChosenContact sheet check before any delivery.

    RejectedNot documented.

    WhyTo spot cut-off text or an overlap at a glance.

What broke

  1. No incident: the pipeline has not run end to end.

Limits to date

  • Never validated on a real deck.
  • Text with several styles loses its formatting when rendered.
  • The logo is not extracted from the brand guidelines.
  • Only one operating system supported.

Dimensionsmeasurements and counts, with how they were measured

3chained skills: brand guidelines extraction, composition, renderingcounted in the repository
13visual layout patternscounted in the repository

Revisions

AMay 19, 2026Pipeline skeleton

Parts listcomponents

  1. 01Brand guidelinesextracted from the client's deck: colors, typefaces, templates
  2. 02Composition rulescommon to all clients
  3. 03Compositioneach page chosen from a set of patterns
  4. 04Rendering and thumbnailscontact sheet before delivery

Notes

  1. The consultant's text is untouchable.
  2. The brand guidelines vary from client to client; the rules stay.

Hatched areas

What this sheet does not show, and will not show:

  • Client brand guidelines and decks

Sources

  • 3 skills, 13 patternsrepository documentation
  • Statusiteration notes in the repository

What this shows

Separating what varies from what stays, and saying that a tool is not yet proven.

Next sheet, C5Research agents for a team

C5

Research agents for a team

An installation kit, agents and skills to get a consulting team working with coding agents: solution benchmarks, vendor profiles, grid audits. The orchestration was redesigned after a real delivery.

Delivered. Kit released in late March 2026; benchmark delivered and audited in April for a leadership seminar; adopted by a consultant for an engagement.

Sheet
C5
Status
Delivered
Type
Team tool
Period
March to May 2026
Role
Design of the agents, skills and kit; fixes after delivery
Context
Consulting, Ascend Partners
Stack
Coding agents and skills, security hooks, tests, continuous integration
History
Versioned; some of the fixes carry a colleague's identity.
Last revision
May 28, 2026
Distribution
Public, hatched areas retained

DiagramPatch bay

How to read At the top, the main session's outputs, one per phase; at the bottom, the agents and the skills. Each cord is a launch: only the main session plugs in a cord. Underneath, the hooks that block certain commands.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Moving from individual use to a team ran into a limitation of the tool: a subagent cannot launch other subagents. The planned cascading orchestration did not work, and this only became apparent after a real delivery.

Decisions

  1. ChosenThe main session orchestrates and launches the agents in parallel; the lead agent now only handles scoping.

    RejectedA cascade of agents.

    WhyA native limitation of the tool.

  2. ChosenTwo installation modes: minimal for non-technical profiles, full for the rest.

    RejectedA single package.

    WhyNon-technical profiles do not need to install everything.

  3. ChosenHooks block destructive commands, reads of sensitive files, and scripts that are downloaded then run.

    RejectedNot documented.

    WhyNever any real client data in the instructions.

What broke

  1. April 20

    The audit following the first delivery finds blocking issues: orchestration revised, document rendering fixed.

  2. An inconsistent figure on one vendor leads to writing a consistency checker.

Limits to date

  • Adoption documented for a single consultant.
  • Tool servers are listed, rarely installed by the kit.
  • The kit also bundles third-party skill packs.

In the field

ClientWhat runsDated status
Consulting firmInstallation kit, hooks, subagentsReleased in late March 2026
Industrial group, leadership seminarMulti-agent benchmark, spreadsheet and summary memoDelivered and audited in April 2026
Mutual health insurance groupAudit of a scoring grid, six bias detectorsMay 2026

Dimensionsmeasurements and counts, with how they were measured

6skills written in-house, for 5 to 7 agents depending on the versioncounted in the repository
58passing tests in the benchmark stackdocumented by the project
139tests passed in continuous integration on the grid auditorcounted in the repository
10 in 78 minvendors processed in a fictitious public administration casedocumented by the project

Revisions

DMay 28, 2026Grid auditor
CApr 20, 2026Post-delivery audit, orchestration revised
BApr 16, 2026Fictitious case: 10 vendors in 78 minutes
AMar 26, 2026Installation kit

Parts listcomponents

  1. 01Main sessionorchestrates and launches the agents in parallel
  2. 02Agentsdiscovery, investigation, critique, red-teaming
  3. 03Skillsfact-checking, source credibility, weighted scoring
  4. 04Hooksdestructive commands, sensitive files
  5. 05Engagement templateone instructions file per engagement

Notes

  1. A tool limitation is handled in the architecture.
  2. No real client data in the instructions.

Hatched areas

What this sheet does not show, and will not show:

  • Clients and deliverables
  • Scoring grids

Sources

  • 6 skills, 5 to 7 agentscount across the repositories
  • 58 and 139 testschangelog, continuous integration
  • 10 vendors in 78 mincommit message

What this shows

Moving agent tooling from one workstation to a team, and fixing it after a real delivery.

Next sheet, P1Compliance pre-review

P1

Compliance pre-review

Before a marketing piece goes to compliance at a US broker-dealer, a pre-review: highlighted passages, missing disclosures, corrections written into the PDF. Only the points that are certain go to the banker.

Prototype. Built for a hackathon, September 10 to 12, 2026. Hackathon result and deployment not documented.

Sheet
P1
Status
Prototype
Type
Hackathon
Period
September 2026
Role
Designed, built and evaluated
Context
Personal and freelance projects
Stack
Python, library-free PDF reading and incremental updating, tool-less single-turn model, SHA-256 hash chain
History
Versioned, 7 commits.
Last revision
Sep 12, 2026
Distribution
Public, hatched areas retained

DiagramCorrected proof

How to read A fictitious page of marketing material, annotated like a printer's proof: each mark in the margin points to a passage in the document. Depending on the scenario, a rule's card and its verdicts, or the chain of verdicts linked by hash.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

The previous version's rules engine produced points a reviewer could not send, and models vary from one run to the next. It had to be clear what could be affirmed.

Decisions

  1. ChosenOnly affirmed points go to the banker; the rest goes to the reviewer.

    RejectedShow everything.

    WhyNever tell the banker what the machine cannot prove.

  2. ChosenA ground truth written in advance, and the previous engine run unmodified on the same corpus.

    RejectedNot documented.

    WhyCompare against the existing system, on known errors.

  3. ChosenReviewer text is data: the model runs without tools, in a single turn, with no session.

    RejectedLet a comment influence the rules.

    WhyClose the door to prompt injection.

  4. ChosenCorrections written as an incremental update to the PDF.

    RejectedRewrite the PDF.

    WhyThe original document stays intact beneath the correction.

What broke

  1. Hackathon

    On the first full pass, three planted points are missed on one document, including a vector graphic read as text. Seven rules fixed before the second pass.

Limits to date

  • The test corpus is written by the author of the rules: it is a regression bench, not a benchmark.
  • The figures come from the second pass, after calibration.
  • Login identifies the user without authenticating them.
  • The correction is an overlay: the original text remains underneath.

In the field

ClientWhat runsDated status
US broker-dealer, hackathonCalibration on a real deck and a reviewer's sheetPrototype, September 2026

Dimensionsmeasurements and counts, with how they were measured

71 → 100%recall on 7 documents with planted errors, versus the previous engine; second passmeasured offline
31 → 4%false positives on the same corpusmeasured offline
60% over 5rejections that demote a rule; 80% over 8 drop itcounted in the repository
$0.32 to $0.82cost per document, for 2 to 5 minutes of processingmeasured offline

Revisions

BSep 12, 2026Last hackathon commit
ASep 10, 2026Engine version 0.2

Parts listcomponents

  1. 01Deterministic passrequired disclosures searched word for word
  2. 02Two model passesmapping the document, drafting the findings
  3. 03Quoteseach finding quotes a passage found in the PDF
  4. 04Correctionsincremental update, document read back after correction
  5. 05Verdictseach decision recorded and chained by hash
  6. 06Client's internal proceduresretained content

Notes

  1. A quote that cannot be found demotes the finding.
  2. A disagreement between reviewers is flagged, never settled by the machine.
  3. Sending stays blocked until the corrections are re-verified.

Hatched areas

What this sheet does not show, and will not show:

  • Client's brand and procedures
  • Real decks

Sources

  • Recall and false positivessimulation report in the repository
  • Demotion thresholdsarchitecture document in the repository
  • Costsimulation report in the repository
  • Datesgit history

What this shows

Turning a compliance rule into a product evaluated against a ground truth and against the existing system, while publishing its own limits.

Next sheet, P2Marine dealer website

P2

Marine dealer website

A dealer's inventory is updated by uploading the PDF spec sheet exported from its business software. A PDF reader written with no dependencies extracts the listing, which arrives as a pull request to review.

In production. Live since August 17, 2026 for a family business; inventory updated on August 19 and September 3.

Sheet
P2
Status
In production
Type
Freelance project
Period
August to September 2026
Role
Designed, built, put into production and audited
Context
Personal and freelance projects
Stack
Static Next.js, custom PDF reader, continuous integration, magic link
History
Versioned.
Last revision
Sep 3, 2026
Distribution
Public, hatched areas retained

DiagramGo/no-go gauges

How to read A file goes through three gauges before it is read: size, pages, decompressed size. It fits or it does not; nothing is forced. Then, the fields pulled from the spec sheet. Fictitious data.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Ingesting a third-party tool's PDF export with no database, no password and no guessing. One file received contained two boats: the resulting listing mixed their photos.

And a rate limit kept in memory does not hold on a serverless platform.

Decisions

  1. ChosenThe PDF spec sheet the team already exports.

    RejectedA marketplace's paid XML feed.

    WhyThe pricing negotiation fell through.

  2. ChosenA custom PDF reader, bounded: 30 MB, 40 pages, 64 MB decompressed.

    RejectedA generic library.

    WhyNo exception may escape from a hostile PDF.

  3. ChosenA missing field becomes "to be confirmed"; the machine never decides between two listings of the same model and never replaces a photo with a worse one.

    RejectedNot documented.

    WhyNothing is guessed.

  4. ChosenA magic link valid for 15 minutes, revocable by changing the secret.

    RejectedA session database.

    WhyNo database to maintain.

What broke

  1. August 17

    Launch-day audit: 14 consecutive requests without rate limiting, and a scheduled task running on a default branch 42 commits behind. Branch fixed, actions pinned by hash.

  2. August 17

    First draft of the admin area: response codes made it possible to guess administrator addresses. Fixed.

  3. August 19

    A PDF contained two boats: spec sheets are now split boat by boat.

Limits to date

  • The rate limit stays in memory; the planned firewall rules are not in place.
  • No branch protection.
  • The client's autonomy is not proven: both inventory updates were made at the client's request.

In the field

ClientWhat runsDated status
Boat dealer, family businessStatic site, inventory updated from PDF spec sheetsIn production since August 17, 2026

Dimensionsmeasurements and counts, with how they were measured

93site tests, including 50 on the PDF pipelinecounted in the repository
632photos carried over from the old site, none lostdocumented by the project
93 and 99Lighthouse performance, home page and listing; local measurement on August 14, before launchmeasured offline
52pages, and 48 redirects from the old sitedocumented by the project

Revisions

ESep 3, 2026Inventory update
DAug 19, 2026Spec sheets split boat by boat
CAug 17, 2026Launch, security audit
BAug 15, 2026Art direction settled, 3D scene removed
AAug 14, 2026Performance measurements

Parts listcomponents

  1. 01PDF readerno dependencies; refuses what it does not recognize
  2. 02Ingestionspec sheet upload, tests, pull request with report
  3. 03Admin area15-minute magic link; no route writes
  4. 04Photosnever replaced by a worse one

Notes

  1. A missing field is marked "to be confirmed".
  2. Every admin action comes back as a proposal to review.

Hatched areas

What this sheet does not show, and will not show:

  • Company, inventory and prices
  • Deployment secrets

Sources

  • August 17, 14 requestssecurity audit report in the repository
  • Reader boundsPDF reader code
  • 93 and 99, 632 photos, 52 pagesoverall report in the repository
  • 93 testscount of test cases

What this shows

Taking a real project through to production, with ingestion that refuses to guess and an audit that measures its own flaws.

Next sheet, P3Merger arbitrage

P3

Merger arbitrage

Reading public tender offer announcements from three European regulators, each in its own format, to extract the offer price and score the opportunity. No order was placed: the project stopped based on its own measurements.

Prototype. Built in May and June 2026, in phases validated one at a time; dormant since.

Sheet
P3
Status
Prototype
Type
Personal project
Period
May to June 2026
Role
Designed and built
Context
Personal and freelance projects
Stack
Python, PostgreSQL and versioned migrations, one parser per jurisdiction, scoring model
History
Versioned.
Last revision
May 25, 2026
Distribution
Public, hatched areas retained

DiagramNotice reading and ROC curve

How to read A fictitious offer notice, in German as in the source, annotated in English: the parser looks for the cash clause, because the first amount is the nominal value. The ROC curve places the scoring model relative to its target.

Reconstruction with fictitious data. The behavior is the system's; the real rules, thresholds and instructions are retained.

Analysis

What the sheet does not say by itself

The real problem

Three regulators, three formats, three different access protections. In German notices, the share's nominal value precedes the offer price: the first amount read is not the right one.

And few labeled failures to train the model on: 7 out of 128 cases.

Decisions

  1. ChosenPhases opened one at a time, upon explicit validation.

    RejectedNot documented.

    WhyDo not build on an unvalidated phase.

  2. ChosenThe offer price is read from the cash clause; a mixed offer stays empty, with a flag.

    RejectedTake the first euro amount.

    WhyThe nominal value precedes it in German notices.

  3. ChosenThe decision is separate from the broker, on public prices.

    RejectedA subscription tied to a real, funded account.

    WhyTest the decision without committing money.

  4. ChosenNo second version of the model on about thirty groups of deals.

    RejectedRetrain.

    WhyOn that basis, the area under the curve would not be reliable.

What broke

  1. May 25

    17 German prices flagged as doubtful: 5 actually wrong, of which 3 corrected and 2 mixed offers left empty.

  2. Migration ID collision: the test database had not been migrated.

  3. First Italian load: stopped after 252 rows, protected files, and sixteen years of history instead of twelve months.

  4. The free price source only succeeds in 25% of real cases: phase stopped.

Limits to date

  • No order executed, not even in simulation.
  • Area under the curve of 0.611, below the 0.65 target; the model mainly distinguishes deals by their type.
  • Deployment pending.

Dimensionsmeasurements and counts, with how they were measured

40 / 42German prices verified against the cash clause after correctiondocumented by the project
0.611area under the ROC curve of the scoring model, against a target of 0.65documented by the project
17schema migrationscounted in the repository
491test functionscounted in the repository
1 / 7decision selected from the candidates of the last phasedocumented by the project

Revisions

BMay 25, 2026German prices corrected
AMay 12, 2026Project start

Parts listcomponents

  1. 01Parsersone per jurisdiction
  2. 02Offer priceread from the cash clause, otherwise empty and flagged
  3. 03Scoringmodel trained on past deals
  4. 04Decisionseparate from the broker, logged

Notes

  1. A mixed offer is never reduced to a single figure.
  2. A phase is only opened once the previous one is validated.

Sources

  • 40 / 42, 17 flaggedfix summary in the repository
  • 0.611scoring document in the repository
  • 25%phase closing summary
  • 17 migrations, 491 testsrepository count

What this shows

Running a data and ML system in phases, and stopping it based on its own measurements.

Next sheet, S1Voice receptionists