factory/vibe/PRD/ai-back-office/poc-plan.md

vibe > PRD > AI back-office > POC plan

POC plan — feasibility proven by real implementations

Status: In design Last Updated: 2026-07-11 Up: AI back-office hub Related: Task inventory · Challenges · QA strategy · STATUS

POCs are real implementations against real data (the live mailbox, the live bank feeds, the iso-prod sandbox) — not demos. Each has a hard exit criterion; a POC that can't meet it produces a documented "no" and a fallback decision, which is also a success. Order follows the roadmap; effort is S/M/L (rough: S ≈ a day, M ≈ a few days, L ≈ a week-plus of focused sessions).

POC-1 — Supplier invoice end-to-end

Flagship — phase 1 · effort L.

Proves: the full A2 loop — the pipeline shape, dual extraction, validators, sandbox rehearsal, Telegram approval, gated promote, GED attach. Covers T01→T04. Build: mail → dual extraction (M4 + Mistral) → validators → manifest → sandbox → approval card → promote → attach + verify, journaled end-to-end. Triage may start as a cron script (Pi model comes in POC-2). Exit criteria: 10 consecutive real supplier invoices recorded in prod with zero human field-corrections (approvals only); critical-field accuracy ≥ 98 % over the full golden set (overall field accuracy reported alongside); all injection fixtures quarantined; every run replayable from its journal. Fallback if failed: stay at A1 (agent drafts, human enters in UI) and iterate extraction only.

POC-2 — Pi sentinel

Phase 3 · effort M.

Proves: a quantized SLM on the cluster can hold the 24/7 watch (T01, T11); closes D6. Build: llama.cpp/Ollama server as an ArgoCD app (arm64, GGUF Q4, 1–4B candidates, GBNF-constrained), resource-limited and node-pinned; triage atom pointed at it; reminder loop from the calendar file. Exit criteria: ≥ 95 % accuracy on the three action classes (supplier-invoice, bank-notice, government-admin) over ≥ 200 historical mails labeled by Claude + human-corrected; p95 classification latency < 60 s; zero k8s evictions of business workloads attributable to inference over a 2-week soak; reminders fire on schedule for a synthetic calendar. Fallback if failed: sentinel runs on M4-wake + Mistral (loses 24/7 — accepted degraded steady-state per C5).

POC-3 — Reconciliation + payment recording

Phase 4 · effort M.

Proves: the weekly money loop — reco findings become gated payment writes with deterministic tx-id linkage (T07, T08). Build: scheduled reco → work items → payment manifests (with transaction_id) → rehearse/gate/promote → next reco matches by id (PASS 0). Exit criteria: one calendar month with zero unexplained deltas older than 7 days; every recorded payment carries its transaction_id and is matched by id (not fuzzy) on the following run; digest reflects reality (spot-checked weekly). Fallback if failed: reco stays A3-report-only; payments stay manual with the agent pre-filling.

POC-4 — TVA dry-run

Phase 5 · effort S.

Proves: €-parity of fiscal preparation (T10) before the 2027 regime switch raises the stakes; de-risks C6. Build: prepare the acompte de décembre 2026 and the CA12 FY-2026 sheets from the ERP (skills exist); simulate 2027-Q1 as a CA3 quarterly sheet from the same data; archive evidence (snapshot hash + sheet) per run. Exit criteria: prepared figures match the actually-filed values to the euro (acompte now, CA12 at filing ~May 2027); the CA3 simulation is validated by the expert-comptable checkpoint (or SIE guidance) before 2027-Q1 becomes real. Fallback if failed: divergences are themselves findings (either a books error or an atom error — both valuable); T10 stays fully manual-verified until parity holds.

POC-5 — Model routing bench

Phase 1, alongside POC-1 · effort S.

Proves: the routing policy with numbers instead of vibes; closes D5 (OCR) and seeds every atom's model_policy. Build: run the same extraction atom across all four tiers on the golden set; score per-field accuracy, latency, cost/doc; include the OCR contenders on the scanned subset. Exit criteria: a published table (accuracy × latency × cost per tier) + routing policy v1 committed to the registry; disagreement-rate baseline established for the dual-extraction design. Fallback: none needed — whatever the numbers say is the deliverable.

POC-6 — E-invoicing readiness spike

Phase 2 — hard deadline 2026-09-01 · effort M.

Proves: Arcodange can receive e-invoices on day one; closes D4 with an ADR (C12). Build: validate Qonto as the PA (plateforme agréée, ex-PDP — operator direction: the capital-deposit bank, DGFiP-registered, e-invoicing included in every plan): activate the e-invoicing address, receive a real or test e-invoice, pull it through the business API (the fleet already authenticates there) into T02's structured schema; archive the original in the GED (the PA is a conduit, never the archive); map the 2027 path — Dolibarr stays the invoicing system of record, so establish how e-reporting data for the KM export invoices reaches Qonto (API push vs. manual) before it becomes mandatory. Exit criteria: reception verified end-to-end (supplier e-invoice → Qonto → API pull → validated draft in the pipeline) before 2026-09-01; ADR merged recording Qonto as the PA; 2027 e-reporting requirements captured as backlog fiches with owners and dates. Fallback if failed: any other DGFiP-registered PA (138 exist as of 2026-06) — switching stays cheap because originals live in the GED, not at the PA; minimum-compliance manual reception via the Qonto UI while the API lane matures.

Challenge coverage

POC	De-risks
POC-1	C1 extraction · C2 write integrity · C3 injection · C8 trust gates
POC-2	C5 SLM ceiling · C7 silent failures (heartbeat pattern)
POC-3	C2 · C7 — the standing money loop
POC-4	C6 fiscal correctness
POC-5	C1 · C4 · C9 — tier diversity with data
POC-6	C12 reform readiness

Cross-cutting: C10 (maintenance) and C11 (M4 availability) are watched across all POCs via the weekly ops review rather than owned by one.