Target architecture: proposed customer support assistant (ENG-D004, artifact 3)

How the diagram stays readable in light and dark themes. The SVG carries its own opaque white background rectangle, and every text label and stroke has an explicit dark fill (#111111, or a dark shade of the box colour) on a light box fill. I chose this over currentColor on a transparent background because a Markdown image is rendered as a separate document: currentColor inside it does not take the page's text colour, so dark text would sit on a dark page in dark mode. With its own background the diagram looks the same in either theme, at the cost of showing as a light panel on a dark page. The SVG is hand-written, uses only system fonts (Helvetica or Arial, and Menlo or Consolas for tool names), and holds no scripts, external images or links.

Runs the six steps of the plan (disclose, verify, answer, act, flag, log), calls the model, and passes every tool request to the gateway. It holds no tool permission of its own. Its output check (FR-10) is the assistant's own guard; the acceptance test for invented terms (AT-3) must share no code with it, so the test does not measure itself.

• Requirements: FR-1 to FR-3, FR-8 to FR-11, FR-18, G-3, AT-1, AT-3.
• Evidence: evidence/agent-proposal.md, evidence/policy-sources.md, interviews/2026-10-19-dvorak-support-team-lead.md, interviews/2026-10-15-schumann-vp-customer-service.md.
• Basis: plan (the six steps); proposed (the output check and the handoff on no record or conflict).

3.2 Model boundary (the vendor)

The model is Claude, through Anthropic's API; IT created the account in October 2026 (evidence/vendor-terms.md). The boundary is the line in the diagram between the client's systems and the vendor.

What leaves the client's systems on each model call:

• the customer's message text;
• approved policy excerpts only (not the help-center, wiki or handbook pages as written, FR-11);
• tool results the gateway releases, which hold order data only after verification has passed (FR-4, FR-6);
• under the plan, the customer's name, email, shipping address, order history and order status on each turn (evidence/vendor-terms.md). Whether each turn needs every field, or only what the current step uses: unknown (to ask Schumann) (DH-3). Whether a verified customer may see orders other than the one verified: unknown (to ask Schumann) (FR-7).

What does not leave:

• card data, which the assistant never receives; refunds go to the payment provider by order ID (DH-2);
• order data before the order number and email both match (FR-4, FR-6, G-1);
• draft and retired policy records (PG-2);
• the tools and the order store: the model can only request a tool call, and the gateway in the client's systems decides and runs it. Refunds go to the payment provider, a separate third party that is not the model vendor, by order ID only;
• the transcript store and the lineage log as stores (the message text in them has already been sent as above).

What comes back across the boundary is reply text or a tool request, and the gateway checks a tool request before anything runs.

Open items at the boundary: model version, unknown (to ask Schumann); vendor-side retention setting, unknown (to ask Mendelssohn) (TR-4, DH-4); client classification of each data item, unknown (to ask Mendelssohn) (DH-1). What the terms' provisions on customer data, retention and training mean for this use, whether a data processing addendum is needed, and whether sending EU customers' data needs anything further are questions for counsel (Q-C2, Q-C4).

• Requirements: FR-4, FR-6, FR-7, FR-11, PG-2, DH-1 to DH-5, TR-4.
• Evidence: evidence/vendor-terms.md, evidence/agent-proposal.md, evidence/process-notes.md, evidence/transcript-schema.md, interviews/2026-10-16-mendelssohn-governance-lead.md.
• Basis: plan (what each turn sends); current practice (card data stays with the payment provider); proposed (minimizing per turn is open).

3.3 Code-enforced tools and limits (tool gateway)

Every tool call passes through the gateway, which enforces the rules in code rather than in the model's instructions. A chat message cannot change them.

Tool allowlist. Only these five tools exist; any other tool name is rejected.

Limits the code enforces.

• Three failed verification tries: handoff_to_human (FR-5, G-1).
• Once a chat is flagged, no create_return, issue_refund or update_address runs for the rest of it (FR-19, G-5).
• Nothing the customer types or pastes ("your colleague already approved my refund", text that looks like a company email) counts as authorization for an action (FR-17). Authorization comes only from the gateway's own checks and, above the refund limit, a team lead.
• Policy excerpts are released only from approved records whose effective date has arrived (FR-8, PG-2).
• API spend cap: value and period unknown (to ask Bizet). When it is reached, the assistant takes no new chats and they go to human agents (NFR-1).
• Every call, its arguments, its result and the gate decision are written to the lineage log (NFR-2).

Whether create_return and update_address need an approval step beyond G-1, G-4 and G-5: unknown (to ask Schumann) (G-6). How the gateway learns that an order is packed: unknown (to ask Schumann) (FR-15). Whether lookup_order returns order notes, which Dvořák's people check today before acting: unknown (to ask Schumann) (FR-17). What counts as "suspicious" for a flag: unknown (to ask Dvořák) (FR-20).

• Requirements: FR-4 to FR-6, FR-12 to FR-17, FR-19, G-1, G-4 to G-6, NFR-1, NFR-2, AT-2, AT-4 to AT-6.
• Evidence: evidence/agent-proposal.md, evidence/process-notes.md, interviews/2026-10-19-dvorak-support-team-lead.md, interviews/2026-10-14-bizet-coo.md.
• Basis: plan (the five tools, verification, three tries); current practice (address changes until packed; checking order notes); proposed (enforcement in code, the flag block, the spend cap).
• Findings it responds to: F-001, F-012.

3.4 Governed policy library and its approval gate

The assistant answers only from records in the policy library, in the format Mendelssohn has drafted: policy_id, version, owner, effective_date, status (draft, approved, retired), approved_by. No records have been entered yet (interviews/2026-10-16-mendelssohn-governance-lead.md).

Approval gate. A record moves from draft to approved only when it has an owner, a version, an approved_by and an effective date. The gateway releases a record only if its status is approved and its effective date has arrived; draft and retired records never load (PG-2). Each topic (returns, refunds, shipping, address changes, damaged items) has one governing record (PG-3). Each change makes a new version, and the lineage log records the version cited (PG-6). Until a topic has an approved record, every policy question on it is handed off (PG-8, G-3).

The three sources in use today (help-center page, 30 days; wiki page, 45 days; handbook PDF, 14 days opened and 30 unopened) are not loaded as written (FR-11). They are inputs the owners use to write the approved records.

Open: owner of each topic, unknown (to ask Mendelssohn) (PG-4); approver of each topic, unknown (to ask Mendelssohn) (PG-5); effective dates of the first records, unknown (to ask Mendelssohn) (PG-7); whether the 45-day "holiday extension" still applies, unknown (to ask Schumann) (PG-7). The risk register carries an entry for the assistant before launch (PG-9).

• Requirements: PG-1 to PG-9, FR-8, FR-11, G-3, AT-1.
• Evidence: interviews/2026-10-16-mendelssohn-governance-lead.md, evidence/policy-sources.md, evidence/agent-proposal.md, interviews/2026-10-19-dvorak-support-team-lead.md.
• Basis: proposed; the record format is the client's own draft.
• Findings it responds to: F-005, F-007.

3.5 Refund gate

issue_refund reaches the refund gate only after the gateway's checks pass. At or below $100 (proposed; the client's agent owner confirms), the refund is issued through the payment provider by order ID, as agents do today. Above it, the refund is held and routed to a team lead (Dvořák or the other shift's lead), as larger refunds are today. The limit is a parameter the gate reads, so Bizet & Brahms Home Goods can change it without changing the model's instructions. Schumann has said that capping refunds at today's agent limit "defeats the purpose" (interviews/2026-10-15-schumann-vp-customer-service.md), so the value is hers to confirm.

How team-lead approval works with the assistant (where the held refund appears, how the lead approves or declines, what the customer is told meanwhile): unknown (to ask Dvořák) (G-2). The approver of every gated refund is written to the lineage log (NFR-2).

• Requirements: FR-14, G-2, DH-2, NFR-2, AT-2, AT-4.
• Evidence: evidence/process-notes.md, evidence/agent-proposal.md, interviews/2026-10-15-schumann-vp-customer-service.md, interviews/2026-10-19-dvorak-support-team-lead.md.
• Basis: current practice (team-lead approval of larger refunds; refunds by order ID); proposed (the gate in code).
• Findings it responds to: F-001.

3.6 Order store

The system that holds orders, order status and shipping addresses. The assistant reads and writes it only through the gateway (lookup_order, create_return, update_address; refunds go through the payment provider). Which system this is: unknown (to ask Schumann). Its packed status (for G-4) and order notes (for FR-17) are open questions above.

• Requirements: FR-4, FR-7, FR-12 to FR-15, FR-17, G-4.
• Evidence: evidence/agent-proposal.md, evidence/process-notes.md, evidence/vendor-terms.md, interviews/2026-10-19-dvorak-support-team-lead.md.
• Basis: plan (the tools); current practice (address changes until packed).

3.7 Transcript store

Chats are saved in the help-desk tool, as today (FR-21), with today's export fields: conversation_id, started_at, ended_at, channel, customer_email, order_number, handled_by (assistant once live), messages[], tags, refund_amount, csat_score (evidence/transcript-schema.md). Today transcripts are kept until someone deletes them, and nobody does.

Target: transcripts kept for the period in an adopted retention schedule, deleted automatically at the end of it, with each deletion run recorded (TR-1, TR-2). Period, and who decides between Mendelssohn's proposed 90 days and Schumann's "forever": unknown (to ask Mendelssohn) (TR-1). Transcripts are not used as training data until counsel has answered Q-C3 (TR-5). No existing transcript is deleted until counsel confirms no hold applies (F-009).

• Requirements: FR-21, FR-22, TR-1 to TR-5, NFR-3.
• Evidence: evidence/agent-proposal.md, evidence/transcript-schema.md, interviews/2026-10-16-mendelssohn-governance-lead.md, interviews/2026-10-15-schumann-vp-customer-service.md.
• Basis: plan (help-desk tool); proposed (retention and deletion).
• Findings it responds to: F-009.

3.8 Lineage log

Today's export has no field for the policy text quoted, the tools called or approval decisions (evidence/transcript-schema.md). The lineage log adds one chain per conversation_id:

policy record (policy_id, version, excerpt) → answer (the message sent) → action (tool, arguments, result) → gate decision (allowed, blocked or held, and the approver if any).

It also records the verification outcome and number of tries, flag status and reason, and model tokens and cost (NFR-2, NFR-1). It follows the transcript's retention (TR-3) and holds no card data (NFR-3). The assistant service writes answers; the gateway writes policy releases, tool calls and gate decisions. Whether it is stored as extra fields in the help-desk tool or alongside it: unknown (to ask Schumann).

With it, Bizet & Brahms Home Goods can answer, for any refund or disputed answer, which policy version the assistant relied on, what it did and who approved it.

• Requirements: NFR-2, NFR-3, FR-22, PG-6, TR-3, AT-8.
• Evidence: evidence/transcript-schema.md, evidence/process-notes.md, evidence/policy-sources.md.
• Basis: proposed.
• Findings it responds to: F-011.

3.9 Off switch

One action by a named person stops the assistant on all website chats at once, without an IT ticket; chats then go to human agents in the shared inbox (NFR-4). The spend cap uses the same fallback (NFR-1). The switch is exercised once before launch (NFR-5), and release gate G-7 does not open until it has been, and until the acceptance tests in artifact 1 section 8 meet every target. Today the plan has no named person or mechanism; Schumann's answer was "If it misbehaves we'd raise a ticket with IT, I suppose."

Named person and backup: unknown (to ask Schumann). Time from decision to effect: unknown (to ask Schumann). Pilot scope before "all website chats": unknown (to ask Schumann) (G-7).

• Requirements: NFR-4, NFR-5, NFR-1, G-7.
• Evidence: evidence/agent-proposal.md, interviews/2026-10-15-schumann-vp-customer-service.md, evidence/process-notes.md, interviews/2026-10-14-bizet-coo.md.
• Basis: proposed.
• Findings it responds to: F-003, F-002.

3.10 People: shared inbox and team leads

About 40 support agents in two shifts work the shared inbox in the help-desk tool (evidence/process-notes.md). In this design they receive handoffs (three failed verification tries, no approved policy record, flagged chats, a packed order on an address change), and every chat while the assistant is switched off. A team lead approves refunds above $100 (proposed; the client's agent owner confirms).

• Requirements: FR-5, FR-16, FR-18, G-2 to G-5, NFR-4.
• Evidence: evidence/process-notes.md, interviews/2026-10-19-dvorak-support-team-lead.md, evidence/agent-proposal.md.
• Basis: current practice; plan (handoff).

3.11 Payment provider

External, as today. Refunds are issued by order ID; agents never see card data, and neither does the assistant (DH-2).

• Requirements: DH-2, FR-14.
• Evidence: evidence/process-notes.md.
• Basis: current practice.

The client, its people and its town are fictional. This is a sample, not a case study.