Product Status · Internal Review

What we are building, where it stands, and what it taught us.

2026-07-03 · companion to the AI Product Guide

00 · THE HIGHEST LEVEL

We're building an intelligence layer.

Between inbound communication and a client's system of record. That's the whole company, stated as plainly as possible. Everything else in this deck lives inside that shape.

Inbound

Email

Calls, other channels

→

The intelligence layer

Workflows live here

Distinct configurations of the same underlying pipeline, each solving one commercial process.

→

System of record

ERP

CRM

Excel, other structured sources

00 · THE HIGHEST LEVEL

Quoting is the first workflow, not the only one.

Each workflow is a different configuration of the same shape. Quoting is the one we've built; aronlight is its reference implementation.

Quoting: live, aronlight Order entry: shape only RMA / returns: shape only Procurement: shape only

Two different kinds of reuse, not one: quoting for a second client (proven, aronlight → Eurocomponents shape) is a different claim from the same layer becoming a new workflow like order entry (unproven, never actually happened). This deck mostly covers the first, because it's the only one we have evidence for.

00 · THE HIGHEST LEVEL

Building this well means tracking two pipelines.

One vertical. One horizontal. Next: what each one means.

00 · THE HIGHEST LEVEL

Vertical and horizontal, defined.

Vertical

What happens to one customer request: Gather → Identify → Parse → Match → Human Loop → Act & Deliver

One instance today: Quoting, running for aronlight. Tracked in the Product Guide.

Horizontal

What happens to the standard: audit, find a gap, curate the lesson in, re-audit against it

Never touches a customer request. Runs the same for any workflow. Tracked in the System Guide.

Why track both: we're changing a lot, fast. Skip the vertical check and the product quietly drifts from what we think it is. Skip the horizontal check and speed quietly becomes carelessness. Neither is optional.

00 · THE HIGHEST LEVEL

Where we stand, on each.

Vertical analysis

Pending a fresh formal sync. Last automated /cpo-map-sync run was the bootstrap, 2026-07-04. 6 registry commits since, kept current by hand, not yet re-verified by the sync itself.

Horizontal analysis

Pending a fresh formal audit. Last /cio-audit aronlight run was 2026-06-28. 6 Guide commits since, none re-checked against the live codebase yet.

Said plainly: both are pending. Neither guide is wrong, both have been kept current by hand this week, but the formal check that verifies hand-kept and reality still match hasn't run on either side. That's next.

From here: a close look at the vertical, Quoting, area by area.

01 · THE VERTICAL, AREA BY AREA

Six areas in a chain, one shared foundation.

01

Gather

Every channel a client's customers use, in one place

02

Identify & tag

What is this: request, clarification, noise?

03

Parse

Items requested, plus the context around them

04

Match

Request × system of record, schema in the middle

05

Human loop

Humans fix cases; their behavior teaches the product

06

Act & deliver

Branded quote, ERP write, delivery

02 · AREA 01

Gather

Shipped

Outlook + Gmail OAuth pollers, 5-min beat

Attachment extraction: PDF, Excel, CSV, ZIP, image OCR

Dedup by fingerprint + provider message-id

Manual .eml upload

Partial / missing

#268Body truncated at 10k chars, no flag

#270Scanned PDFs never reach the vision path

#252 P0Reply has no structural link to its case

not trackedWhatsApp, phone calls

Priority: #268 → #270 → the #252 thread model the moment its workflow questions are answered.

02 · AREA 02

Identify and tag

Shipped

Classifier with confidence gate

Full audit log of every decision

Customer match at intake

Partial / missing

#252Clarification reply tagged INQUIRY, silently discarded

#198No email-direction awareness: supplier mail misread as RFQ

futureCase types beyond RFQ (orders, returns, after-sales)

Worst silent failure in the product: a client asking a question gets no row, no extraction, no signal, just silence.

02 · AREA 03

Parse

Parse output is not a list of items. It is items plus a context ledger. "Outdoor project" constrains every item's IP rating. "Like this SKU but horizontal" is a reference plus a modification, not free text.

Shipped

Line-item extraction + prompt-injection defence

Spec normalizer + extractors (watt, lumen, kelvin, IP, dims, UGR)

Partial / missing

#271One whole-email context only: mixed projects unmatchable

not trackedThe context ledger · relational requests

#271 is the flagship known bug: headers detected, then dropped. It gates the extraction restructure and is where this belief was born.

02 · AREA 04

Match

Parsed request on one side, the client's system of record on the other. The attribute schema is the bridge. This is where the value technology concentrates.

Shipped

Cheap-first chain: code → register → competitor → retrieval → judge

LLM catalog enrichment with human review

Partial / missing

#277Schema still lives in code, not a written artifact

#277/2782 live invariant violations: CRI, UGR judged with no data

Method: attribute-schema-bootstrap-playbook.md. Derive it once, checkably, never through incidents.

02 · AREA 05

Human loop: two loops share the screen

Loop 1: fix this case

Two-panel review UI, quote builder

Per-item override, assignment, locking

Loop 2: teach the product

44-case eval corpus, 3-phase reporter

not trackedBehavioral signal taxonomy · coverage KPI

Loop 2 is the biggest gap. Only the final SKU correction is captured. The coverage KPI (diffing Odoo orders against platform-created ones to catch bypass) is cheap to build and unmeasured today.

02 · AREA 06

Act and deliver

Shipped

Quote PDF · Excel export

Idempotent Odoo draft order, never auto-confirms

Partial / missing

Delivery stub: hardcoded to an internal address

Automated send · fiscal compliance · translated output

02 · FOUNDATION

The trust cluster: pending, urgent

The boring substrate every product shares, built once. Four urgent audit findings sit here; none are optional before a security claim to a client.

Shipped

Async workers, retry, cost tracking per call

JWT auth, error monitoring, prod Docker profile

Missing, urgent

LLM gateway · EU data residency · ZDR contract

Field encryption · secret manager · tenant_id · rate limiting

03 · ARONLIGHT

Where we are

Live in production at aronlight.adaptto.ai, running the full chain end to end on an all-Haiku pipeline with per-call cost accounting.

Now

#262 deterministic baseline: shipped #297/#299 lifecycle status: shipped #258 mounting: shipped end-to-end #309 adjustability retrieval (P0, live edge)

The live edge right now: #309, adjustability retrieval. Extraction and catalog data both existed, the judge could reason about it, and the system still quoted the wrong fixture, because retrieval never surfaced the correct one for the judge to see. Next slide: why that keeps happening.

03 · ARONLIGHT

Three invariants, each found one incident deeper

The attribute schema records, per attribute: can we extract it, does the catalog have it, can retrieval act on it. All three came from the same original case, resurfacing one layer deeper each time.

01

Discriminator invariant.If two products differ only by attribute X, X must be extractable. LUKE (fixed) vs. Torq (rotable): nothing extracted adjustability. RFQ #120.

02

Judge data-path invariant.Every attribute the judge verdicts needs data on at least one side. Fixed, but the wrong fixture still shipped.

03

Retrieval data-path invariant.The judge can only rank what retrieval hands it. Extraction + catalog data existed; retrieval never used them. #309, found a day after the prior fix closed citing this case as resolved, without re-running the eval.

The pattern underneath the pattern: an attribute can satisfy every invariant written down so far and still fail, because each one was discovered by the specific way the previous ones weren't enough. Expect a fourth. The list is a floor, not a ceiling.

03 · ARONLIGHT

The schema, concretely: one row per attribute

Not a diagram of the idea, the actual table: for every attribute the judge can verdict on, does the request side have it, does the catalog side have it. Missing either side is where a confident-looking wrong verdict comes from.

Attribute	Request	Catalog	Status
category / mounting / IP / wattage / CCT	✓	✓	End-to-end
cri	✓	✗	Zero-data verdict
ugr	✓	names only	Kept — proven incident
voltage / beam_angle	✓	✗	Not even in the live prompt
adjustability	✓	✓	Retrieval-blind — #309
lumen / dimensions	partial	✓	Has data, not judged

Where it lives: docs/attribute-schema.md, aronlight repo — drafted this session from merged code (retrofit Step 5 of the bootstrap playbook), not yet validated against Flávio's decision tree. PR open, in review.

03 · ARONLIGHT

What building it taught us

01

Schema first, never incidents.Four same-class matching bugs in a week were all knowable in week zero.

02

Silent failure is the default state.Truncated emails, blank OCR, discarded replies: none threw an error.

03

You cannot improve what you cannot measure.±10-point eval noise was hiding every real regression.

04

Catalog data quality beats matcher cleverness.1,000+ uncategorized products explain more misses than any ranking bug.

05

Closed does not mean done.Security issues closed without implementation created false confidence.

06

Structure must survive parsing.Flattened headers and columns make downstream matching structurally impossible.

07

The human loop only teaches if it's wired.Corrections were captured, not fed back. Learning is built, not assumed.

08

Closing an issue isn't closing the gap.Twice now, closed without implementation or without re-running the eval. Verification needs evidence, not a merged diff.

09

An invariant list is a floor, not a ceiling.Two invariants shipped; a production incident found a third. Expect a fourth.

04 · TWO PIPELINES

Where the pipelines disagree is the roadmap.

The gap between what the horizontal pipeline requires and what the vertical pipeline has built is the work list. This week an audit of the two-guide system itself found two more "closed but not done" incidents in the guides' own upkeep.

01

Adjustability retrieval#309: the live edge of the schema work

02

The trust clusterGateway, ZDR, encryption, secrets, corpus anonymization: still the top unresolved finding

03

Schema formalization#277/#278: still lives in code, not in docs/attribute-schema.md

04

Stable IDs55 checklist items, 3-and-growing invariants: neither has a durable citation anchor

05

Adaptto Core decision#55: lands once, hard to retrofit

05 · WHAT MATTERS MOST

Not just "an AI that reads emails."

01

Context is the moat

Items are easy. Understanding that "outdoor" constrains every item, or that a tender implies specs nobody wrote, is the hard and valuable part.

02

The schema is the technology

Between a messy request and a 4,300-product catalog sits a checkable, portable schema. Checkable turned out to mean three invariants deep so far, not one. It turns a wrong quote into a build failure.

03

The product learns from use

Every accept, override, and abandonment is a verdict on one part of the chain. Wiring these signals is what compounds.

06 · NEW CLIENTS

What onboarding looks like, area by area

Because every client is a configuration of the same chain, coverage reads per area.

Area	Second lighting client	New vertical
Gather	Strong	Good
Identify	Strong	Good
Parse	Good	Partial
Match	Strong	Partial
Human loop	Strong / Weak	Same
Act	Good	Partial
Foundation	Weak	Weak

The two weak cells are the same for every client. That's exactly why they rank high on the roadmap. Paid once, every client benefits.

Full detail

The registry behind this story

ai-product-guide.md: every claim, file path, and issue number

ai-system-best-practice-guide-reviewed.md: the best-practice lens

attribute-schema-bootstrap-playbook.md: the engagement method