Where We Are, Where We Go

Phase 2.5 is the current build target: move the proven AirRouterBot experience onto the dedicated dev server, bind each assigned Android or Telegram user to one of three isolated CHR homes, and retain encrypted, audited development evidence. The later management-overlay feasibility test begins only after Phase 2.5 operational readiness is accepted.

Phase 2.5 dev environment Three MikroTik CHR routers Android + Telegram 88 policy-gated tools 13 agent skills Open server demo Open server architecture

Truth boundary: Phase 2.5 remains an in-progress dev build. Three-home CHR, client-lab, gateway, and isolation artifacts exist, but end-to-end Phase 2.5 operational readiness has not yet been accepted. No WireGuard management overlay is implemented or claimed; that feasibility exercise is planned only after the Phase 2.5 entry gate closes.

Phase 2Proven

Single-Home CHR Lab

Router truthOne MikroTik CHR proved DHCP, RouterOS reads, measured counters, and confirmation-gated changes.
Agent surfaceTelegram, voice input, 85 tools, and 11 skills exercised the preserved AirRouterBot engine.
Client storyLocal fixture clients made the guided demo repeatable before multi-tenant server work.
BoundaryThis was a local lab, not the multi-user Phase 2.5 service.

What this proved The agent can understand the home network and use one safe RouterOS control path.

Phase 2.5Build current

Three-Home Server Build

Three routersrouter-one, router-two, and router-three own non-overlapping 10.201.[1-3].0/24 homes.
Shared client interfaceAndroid and Telegram call the same ConversationService and canonical AirRouterBot engine.
Server authorityFirebase + Telegram 2FA resolves the user, role, tenant, and assigned router before the model runs.
Developer visibilityAdmin/support can inspect encrypted chats and redacted debug records; each read is purpose-labelled and audited.
Phoenix linkA turn stores an opaque trace ID only after Phoenix accepts the content-free span; rejected exports never publish a false join key.

Entry gate before overlay work Prove the three homes, intended clients, assignments, RouterOS reads, audit path, isolation suite, stable baseline, and rollback end to end.

Phase 3Next

Hybrid Real-Router Lab

Add Home FourA dedicated physical MikroTik joins the three CHR homes; the CHRs remain deterministic regression fixtures.
Safe attachmentIts uplink or management side uses an externally isolated, wk01-reachable transport segment while real clients stay behind a separate LAN/Wi-Fi.
One node contractThe same trusted Air Router node, registry, assignment, policy, adapter, and audit path manages all four routers.
Portable placementThe node can later move from an isolated wk01 runtime to a dedicated VM with stale-node fencing.
AcceptanceVirtual and physical RouterOS behavior is compared without claiming a customer or production fleet.

What Phase 3 would prove One safely isolated management contract can serve the three VM homes and one real-router home together.

Phase 2.5 development policy. Clients can read their own history; cross-user staff inspection is available only through authenticated, purpose-labelled, audited admin/support reads so failures can be diagnosed quickly. Phoenix remains content-safe: it receives operation, dev environment, router, outcome, and an opaque trace identity — never message text, chat IDs, tool arguments, credentials, exception text, or raw router payloads.

Air Router — High-Level Architecture Proposal

A controlled home-user proof for a parent or bill payer: one router and one chat channel, to be selected and approved, one demo environment, and a deliberately small set of understandable questions and reversible actions.

v0.2 draft Discovery + planning One router + one chat No implementation authority

Proposal truth boundary: this page visualizes the original first-POC scope. The roadmap and engineering pages elsewhere in this document separately show the proven Phase 2 lab, the unaccepted Phase 2.5 three-home target, the planned Phase 3 hybrid lab, and the later Phase 04 production boundary. Those later stages are not implementation claims made by this proposal.

01 interfaceChat channelReceives one authorized user's plain-language questions after channel approval.

02 authorityIdentity + rolesMaps admin, limited, read-only, and controlled support powers.

03 intentAI orchestrationUnderstands the request and proposes a safe query or candidate action.

04 safetyPolicy + confirmationRefuses unsupported work and confirms risky or reversible changes.

05 integrationRouter adapterUses only the approved management interface for the selected router.

06 valueDiagnostics + reportsTurns device, usage, history, and issue data into useful answers.

07 evidenceAudit + supportRecords requests, approvals, outcomes, failures, and intervention.

Execution boundary

The natural-language session requests approved tools only. It does not receive router credentials, open RouterOS sessions, or send raw commands. Policy, target confirmation, rate limits, and audit decide whether an action may proceed.

Approved tools only

What the first POC is intended to prove

One authorized primary user can ask plain-language network questions.
Connected devices are understandable enough to choose the right target.
Device block and unblock require confirmation and remain reversible.
Usage, past-issue, and selected diagnostic answers are useful.
A controlled support override can be demonstrated with defined limits.
Questions, approvals, changes, refusals, and failures leave basic audit evidence.

What the first POC does not claim

No live customer rollout, production certification, or fleet-scale readiness.
No multiple router brands or enterprise, ISP, or multi-tenant dashboard.
No full firewall management, billing, or payment integration.
No advanced autonomous optimization or silent configuration changes.
No setting change without clear authority, exact target, and confirmation.
No claim that the later Phase 2.5, Phase 3, or Phase 04 designs are complete.

From Client Inputs To An Acceptance Decision

VanillaTech closes the decisions that make the POC safe and testable; Oxiom then moves through five proposal delivery steps and returns evidence against a jointly approved acceptance boundary.

Inputs Delivery steps Acceptance evidence Risk controls

Naming boundary: the five proposal delivery steps below are not Air Router technical phases. They do not replace Phase 2, Phase 2.5, Phase 3, or Phase 04 in the engineering roadmap.

Input 01Router + labModel, firmware, baseline, approved management method, location, devices, Internet link, and topology.

Input 02Identity + controlChat channel, account ownership, role powers, approved actions, confirmation, and revocation behavior.

Input 03Data + evidenceDiagnostic cases, available telemetry or fixtures, privacy/retention policy, demo script, artifacts, and sign-off owner.

Input 04Authority + supportNDA, engagement authority, IP/data ownership, support override powers, limits, audit, and commercial terms.

Five delivery steps Each step pairs an outcome with a VanillaTech decision. Technical phase numbering remains unchanged.

Step 01Requirements closureApprove scope, exclusions, reviewer, and contract state.

Step 02Technical discoveryConfirm router, access method, lab, and chat channel.

Step 03POC designApprove roles, safety guard, test plan, and demo script.

Step 04Controlled build + testProduce a working controlled demo against the selected router using agreed data and access.

Step 05Demo + acceptanceReview evidence, sign off, and decide the next phase.

Evidence 01Authorized identityThe intended user can ask scoped network questions.

Evidence 02Safe controlBlock/unblock is confirmed and reversible; unsupported or risky actions are refused or held.

Evidence 03Useful answersUsage, issue history, and one diagnosis make sense in plain language.

Evidence 04TraceabilityArtifacts show what was requested, approved, changed, failed, or refused.

Risk -> controlIntegration + telemetryConfirm the router interface and available data or fixtures before build.

Risk -> controlAmbiguity + device identityShow the exact target and action, then require confirmation before change.

Risk -> controlAccount + support authorityBind ownership, revocation, override powers, limits, and audit before implementation.

Next step Run the VanillaTech requirements-closure session using docs/client-questions.md, then update the detailed requirements and proposal with the confirmed answers. Detailed implementation planning stays held until router access, chat channel, permissions, acceptance evidence, and contract boundaries are approved.

Target Phase 2.5 Server Architecture

The target server owns identity and router assignment before natural-language reasoning. The same conversation service supports Android and Telegram, writes encrypted dev history, and emits a content-free Phoenix trace that staff can correlate from the audited chat view. End-to-end readiness remains pending.

DEV only Firebase + Telegram 2FA Encrypted chats Audited staff reads Content-free Phoenix Open admin Open interactive demo

Current status: this page describes the Phase 2.5 target and its intended evidence boundary. It does not claim that every component, client VM, live route, or acceptance gate is complete. The management-overlay feasibility extension remains documentation only.

01 identityFirebase passwordConfirms the Air Router account.

02 possessionTelegram 2FAConfirms the privately linked Telegram user.

03 authorityServer assignmentResolves user, tenant, role, and router.

04 memoryConversationServiceLoads encrypted owner-scoped history.

05 reasoningAirRouterBot engineSelects policy-gated skills and tools.

06 networkAssigned CHR onlyUses one server-selected router profile.

07 evidenceChat + PhoenixAudited content joins only to a receiver-verified safe trace ID.

Home Onereadiness pending

router-onevanilla-home-one-dev
10.201.1.0/24

Configured clientsKitchen speaker · Family TV · Work laptop

Home Tworeadiness pending

router-twovanilla-home-two-dev
10.201.2.0/24

Configured clientsGaming console · Tablet · Study laptop · Camera

Home Threereadiness pending

router-threevanilla-home-three-dev
10.201.3.0/24

Configured clientsSmart TV · Phone · Office PC

Developer visibility loop

Choose Home One, Two, or Three in the interactive demo.
Conversation metadata refreshes without decrypting content.
Select a chat and provide the visible Phase 2.5 debugging purpose.
The backend decrypts redacted messages/debug for staff and records the read audit.
Copy the encrypted debug record's phoenix_trace_id and open project air-router-demo.

Planned Hybrid Air Router Node

Once Phase 2.5 is stable, one portable trusted node can manage the three CHR homes and then add a physical MikroTik as Home Four. The same server-owned router registry, signed-job boundary, RouterOS adapter, API-SSL policy, and audit contract serve virtual and physical profiles.

PLANNED only No wk01 mutation 3 CHR + 1 physical Portable node VM No LAN routes No peer forwarding

Hard entry gate: do not configure WireGuard, rebind RouterOS services, attach the physical router, or change the wk01 network until Phase 2.5 readiness is accepted and a successor change authorizes the hardware and network boundary. “Same network as wk01” means controlled routed reachability on an externally isolated transport segment — never unrestricted Layer-2 adjacency. Home Four's real-client LAN/Wi-Fi stays separate.

01 prerequisitePhase 2.5 readyStable three-home system and rollback evidence.

02 authorityReviewed changePromoted requirements and mutation scope approved.

03 nodePortable nodeMachine identity, registry, and router-scoped secrets stay outside the NL runtime.

04 virtualThree CHR peersProve the common contract against Homes One to Three.

05 physicalAdd Home FourExternally isolated transport; separate real-client LAN/Wi-Fi.

06 proofHybrid isolationNo L2, peer, LAN, host, forged-source, or alternate management path.

07 evolutionDedicated VMRevoke old-node lease, secrets, and transport/API identity before activation.

Control Boundaryserver-selected router only

Identity + policy brokerResolves tenant, account, role, assigned router, action, confirmation, and limits.

Air Router nodePortable machine-bound runtime containing the router-access gateway; exact WireGuard UDP transport, API-SSL adapter, no forwarding.

four independent management spokes · one active node per router

Router Boundariesno shared customer VPN

Home One CHRNode /32 only · no other peer or LAN route.

Home Two CHRNode /32 only · independently revocable identity.

Home Three CHRNode /32 only · API-SSL bound to management path.

Home Four physicalIsolated wk01-reachable transport · real clients on separate LAN/Wi-Fi.

What The Hybrid Test Can Prove

One node can manage three CHRs and one physical MikroTik through one common contract.
External ACLs deny Home Four any Layer-2/Layer-3 path except the active-node WireGuard flow.
Client IPv4/IPv6 drops precede FastTrack/general accepts; unapproved destination-NAT flows stay disabled.
The node can move to a dedicated VM only after old-node lease, secret, and transport/API revocation.

What Remains Held

Internet, NAT/CGNAT, ISP firewall, and DNS reliability.
No hardware is attached and no node runtime or dedicated node VM is deployed by this plan.
Customer, production, security-certification, and rollout claims.
Implementation authority; the detailed architecture remains a draft planning record.

Tools: How The Agent Safely Touches A Router

The natural-language agent never runs raw RouterOS commands. It acts only through 88 policy-gated tools — a fixed, audited vocabulary of safe operations. Reads answer questions; every change is prepared, never applied by the model, and waits behind an explicit confirmation. This is the layer skills build on.

88 policy-gated tools No raw commands Prepare, never apply Least-privilege user

Why tools instead of a shell: a raw command string is opaque and unstoppable; a typed tool call is inspectable, gate-able, and auditable. The model chooses which tool and with what inputs; the bot's policy layer — not the model — decides whether it may touch the router. A compromised or mistaken model still cannot apply a change, escape its session, or reach the management plane.

~48 read tools Devices, WAN, DNS, ARP, routes, NAT, firewall, queues, services, CAPsMAN, schedules, security audit, change history. Read-only: they answer, they never change state.

~35 prepare tools Block, limit, prioritize, port-forward, firewall rule, DNS filter, schedule, reserve IP, VLAN. Each stages a pending change with a preview — it does not apply it.

2 hidden apply tools The only tools that write to the router are never exposed to the model; the deterministic confirm path invokes them after human approval.

01 Model picks a tool From the catalog only. A hot set stays loaded; the rest are discovered on demand via tool search, so the model reasons over a focused, valid vocabulary.

02 Policy gate decides The bot — not the model — checks the tool, its inputs, and the session's scope. Reads run; a prepare tool stages a pending change; forbidden or management-plane actions are refused.

03 Prepare, with a preview A change tool returns exactly what it would do (the RouterOS command preview) and stores a pending action bound to a confirmation code — nothing has touched the router yet.

04 Human confirms, bot applies Only an explicit confirm (typed code or button) triggers the hidden apply tool. The model can request, preview, and explain — it can never be the thing that writes.

Why this is safe for a client router guardrails

Least-privilege RouterOS user The bot connects as a restricted account (read, write, test, api) — reboot, factory reset, and user management are not even reachable.

Guard-railed writes Firewall edits are forward-chain only; NAT keeps base masquerade; interface toggles refuse the WAN/management plane. A management lockout is structurally impossible.

Content-bound confirmation Each pending change carries its own code and expiry; a bare "yes" cannot apply a high-risk or network-wide change, and stale confirmations are refused.

Every call audited Tool name, inputs, gate decision, and result are logged — the whole interaction is reconstructable after the fact.

Tools vs skills two layers

Tools are the verbs Single, safe operations — read a table, prepare one change. Small, typed, gated. The agent's only way to touch the router.

Skills are the workflows A complex request ("set up QoS", "block adult sites") is not one tool — it is a sequence: read the right tables first, ask for missing inputs, then prepare. Skills encode that sequence.

Skills orchestrate tools A skill never bypasses the gate; it just tells the agent which tools to use, in what order, and what it may not claim. Same primitives, coordinated for a real task.

Simple stays simple "Pause the TV" is one prepare tool and a confirm — no skill needed. The skill layer only engages when a request needs a multi-step workflow.

Why The Agent Needs A Skill Layer

The next reliability issue is not whether RouterOS can be changed; it is whether the natural-language agent knows when a feature needs a workflow. QoS, firewall rules, and DNS category filtering all look like short chat requests, but each needs different router reads, missing inputs, claims, and confirmation gates.

10 RouterOS skills live Inspect or ask No fake confirm Future setup profiles

Issue being addressed: the LLM can otherwise skip the real workflow, call a read/status tool, then write a convincing "Reply confirm" message without a pending action or enough router context. Skills make that impossible to treat as done: the live catalog now has 10 contracts for baseline truth, safe change, NAT exposure, firewall rules, security hardening, DNS filtering, schedules, Wi-Fi/CAPsMAN, QoS, and rollback.

01 User Intent "Give TV priority" may be simple; "set up QoS", "add a firewall rule", and "block adult sites" each need a different workflow.

02 Skill Trigger QoS, firewall, DNS filtering, NAT exposure, security, schedule, Wi-Fi, or rollback language activates the matching skill.

03 Investigate Use the matching RouterOS reads first: devices, queues, WAN, DNS, firewall, NAT, CAPsMAN, schedules, or history.

04 Prompt Gaps Ask only for the missing inputs: QoS rates/classes, firewall action/match, DNS filter profile, target device, time window, or rollback scope.

05 Prepare Only Use a prepare tool only when inputs are complete and the tool exists.

06 Confirm Gate Confirm appears only from pending state; the LLM cannot invent it.

Problem Class bug

False readiness The agent can sound certain even when it has not staged a router change.

Workflow collapse One-device priority, full QoS, firewall rules, and DNS category filtering can be collapsed into the wrong tool.

Missing inputs QoS needs rates/classes; firewall rules need action and match; DNS category filtering needs malware-only, family/adult, or off.

Router boundary CHR can shape routed WAN traffic, but cannot prove physical Wi-Fi airtime; DNS category filtering depends on provider classification, not an Air Router-owned complete site list.

Skill Contract live

Tools it may use Devices, queues, WAN, DNS, firewall, NAT, services, CAPsMAN, schedules, recent history, and speed test with permission.

Questions it must answer Can this be answered from router config, should the user be prompted, or can a prepare tool run?

Claims it must not make No full QoS claim from a lightweight queue; no management-plane firewall edits; no complete adult/harmful site-list claim.

Confirmation rule No "Confirm" step unless a prepare tool created pending state.

Future Build-Out next

QoS setup profile Add the RouterOS parent/child queue profile tool once WAN rates, class defaults, guarantees, and caps are approved.

More setup-profile tools Local DNS records, guest Wi-Fi, richer content-filter providers, and vendor-specific baselines can get prepare tools under the skill layer.

Vendor adapters RouterOS, OpenWrt, UniFi, and ISP CPE need different setup plans under one capability request.

Production control plane Skills become tenant-scoped policy workflows before any per-router execution.

Phase 04: Multi-Tenant Control Plane

At production scale, every WhatsApp conversation is converted into a tenant-bound control session before any router action is possible. The bot can be conversational; the execution path stays policy-controlled and router-scoped.

WhatsApp support portal Tenant-bound NL session Policy-owned tooling Per-router management path

Main boundary: the natural-language container can ask for tools, but it cannot connect to routers, choose arbitrary router IDs, or read secrets.

identity WhatsApp User Authenticated by the support channel and mapped to a backend user.

ingress Bot Gateway Creates the tenant, user, chat, and router context for the request.

session NL Container Receives scoped memory and sanitized tool results only.

guard Policy Broker Validates action, target router, role, confirmation, and rate limits.

tools Router Tools Bounded operations such as list devices, diagnose, pause, restore, isolate.

access Router-Access Gateway Runs inside the Air Router node and uses router-scoped secrets and tunnel identity outside the NL runtime.

network MikroTik Router One customer router, one scoped management path, no cross-tenant route.

Identity First tenant_id, user_id, chat_id, and router_id are assigned before NL reasoning. Bounded

Memory Scope Chat history and network context stay scoped to that tenant and router. Tenant

Execution Gate Only the policy broker can approve tool execution or deny risky requests. Policy

Router Access Each MikroTik uses a router-specific management channel and least privilege API. Isolated

Phase 04: Trust Boundaries

Each customer router remains a separate security boundary. The natural-language session only receives tenant-scoped context and sanitized tool results; policy and tooling own every execution decision.

Tenant-bound session Policy-owned execution No LLM router credentials Per-router tunnel Audit every action

Production rule: conversation is flexible, but execution is controlled. The NL agent can request approved tools only; policy decides what may touch a router.

Identity Boundary trusted backend IDs, not prompt text

WhatsApp identity Verified channel user and support account metadata.

Tenant binding Backend assigns tenant_id and user_id before any agent step.

Router binding Allowed router_id is selected from account entitlement.

context envelope only

NL Session Boundary memory and reasoning, no direct execution

Session memory Chat history is scoped to tenant, user, chat, and router.

Intent parsing The model proposes tool intent, never raw RouterOS access.

Sanitized outputs The model sees tool results, not credentials or tunnel keys.

approved tool request only

Policy And Tooling Boundary execution authority lives here

Policy broker Checks role, action type, target device, confirmation, and limits.

Job queue Queues work to the one router this session is allowed to manage.

Audit trail Records requester, decision, tool call, result, and support override.

router-scoped management call only

Router Boundary one isolated management channel per router

Outbound tunnel Router initiates WireGuard or mTLS management access to the gateway.

Least privilege API MikroTik API user is limited to approved read and control actions.

What The NL Session Cannot Do

It cannot see router credentials, tunnel keys, or secrets.
It cannot pick tenant_id or router_id from user-provided text.
It cannot send raw RouterOS commands or open low-level network access.

What Policy Owns

Session-to-tenant, user, chat, and router authorization.
Tool allow-list, confirmation gates, rate limits, and denied actions.
Support access delegation with expiry and full audit records.

Breach Containment

A breached WhatsApp account can only reach its authorized router scope.
A compromised router tunnel key is revoked without affecting other tenants.
No flat VPN or shared router-admin credential can affect every network.

Repeatable Demo Run Across The Three Stages

The demo improves because the same scenario travels forward: controlled client behavior, voice-note commands, spoken replies, RouterOS observations, confirmed actions, and a sanitized evidence pack.

20 minute default run 5 minute segments Router insight before control Voice-note command coverage Staging before rollout

01 Start Baseline Current bot, browser mirror, and token health are confirmed without exposing secrets.

02 Run Scenario Phone, laptop, and TV follow timed traffic behavior for the selected stage.

03 Observe Router Read device names, leases, counters, and current block state.

04 Use Voice Notes Send voice notes to list, diagnose, pause TV, confirm, unblock, and handle unclear requests safely.

05 Confirm Actions Preview first, then use confirmed WAN block/unblock actions in lab mode.

06 Capture Proof Store chat, voice transcripts, spoken replies, browser mirror, RouterOS export, and client playbook logs.

Phase 2 Single-Home CHR proven

Product experience The Docker bot/UI and browser demo established the conversational product behavior.

Router fidelity One MikroTik CHR established DHCP, RouterOS reads, counters, and confirmation-gated control.

Evidence boundary This is the proven single-home foundation, not the Phase 2.5 three-home operational state.

Feeds Phase 2.5 The agent, tool, confirmation, and evidence contracts move forward into the three-home build.

Phase 2.5 Three-Home Build current

Three isolated homes The target combines three CHRs, their intended clients, server assignments, and one shared gateway.

Operational entry gate Clients, RouterOS reads, audit, isolation, stable baseline, and rollback must pass end to end.

Overlay remains planned No WireGuard or API rebinding starts merely because the architecture has been documented.

Feasibility extension Only an accepted Phase 2.5 state and separately approved change may open the overlay test.

Phase 3 Hybrid Physical Staging later

Add physical Home Four Run the reviewed RouterOS baseline on a dedicated MikroTik while retaining all three CHR regression homes.

Separate real-client LAN Use dedicated devices behind Home Four; only an externally isolated transport segment is reachable from wk01, with no shared Layer-2 adjacency.

Portable Air Router node Manage all four homes through one registry and adapter contract, then revoke the old node's lease, secrets, and transport/API identity before VM activation.

Staging validation Real hardware and hybrid isolation are validated before any customer or rollout decision.

How The Agent Stays Reliable And Cheap

A capable agent still fails a demo if it forgets the conversation, mis-routes a phrase to a canned reply, re-uploads its whole toolset on every turn, or hides an error behind a confident answer. Four mechanisms keep the natural-language agent trustworthy at low cost.

Agent-first routing 24-turn memory Prompt cache + tool search Honest failure

Measured on the live model: the fixed per-request prefix dropped from about 29,500 tokens to 5,848 (tool search defers 67 of 85 tool schemas and discovers them on demand), and that prefix is then served from cache on every follow-up round trip. Every model reply carries its cache-read and token counts into the audit log.

01 Agent-first routing Only exact control words (help, cancel, confirm) and bulk actions run deterministic matchers before the model. Everything else reaches the agent, so an odd phrasing is never hijacked by a keyword to a canned reply. The keyword tree remains as the agent-off fallback.

02 Conversation memory 24 recent turns travel with each request, stored with head-and-tail truncation so a long answer keeps its "Next step" ending. Follow-ups like "did that work?" and "fix all of them" resolve against real context instead of restarting.

03 Efficiency: cache + tool search The frozen system prompt and a 16-tool hot set sit behind a prompt-cache breakpoint; the rest of the 85 tools are deferred and pulled on demand by the model's tool-search tool. Repeat round trips read the prefix at about a tenth of the price.

04 Honest, observed failure If the model returns nothing usable, the agent degrades to the deterministic path and, as a last resort, says so plainly — never a canned line that impersonates a decision. Every exit emits a distinct audit event, so a silent stall cannot recur unnoticed.

What a client feels experience

It remembers "Run a security audit" then "fix all the items" works as one thread — the audit findings carry into the fix request.

It answers the question asked "We set up TV priority — did that not work?" is answered, not met with an onboarding card.

Two people at once Per-conversation worker queues keep each chat ordered while different chats run in parallel; a confirm tap never waits behind another chat.

How it is kept true verification

Boundary fault tests The model API's failure modes (empty reply, timeout, bad tool call, budget exhaustion) are each asserted to fail honestly and leave an audit trail.

Golden journeys Real multi-turn conversations replay in the suite so routing, memory, and confirmation regress together, not one feature at a time.

Deploy smoke gate After every rebuild, key journeys run against the live model and router; "deployed" means the smoke passed, not that a health check returned 200.