Loomworks Example Generator — change request — v0.2

Version. 0.2 Date. 2026-06-11 Status. Build specification for the marketing-site Example Generator. Scope is fixed by loomworks-example-generator-scoping-note-v0_3 (all eight decisions Operator-confirmed), superseding the prior v0_2 reference. Technical consumer: Claude Code on DUNIN7-M4. Markdown primary. Render-type. Change request. CC-facing. Source. loomworks-example-generator-scoping-note-v0_3; loomworks-example-generator-investigation-v0_1; loomworks-api-glossary-v0_3; CC recon of DUNIN7/foray-kaspathon (Business Analyzer) and DUNIN7/foray-protocol.

Change from v0.1. Adds D8 — the take-away (a Foundation Document draft) as a new build surface after the D7 two-step-chain section: a separate prospect-triggered action that issues a third glossary-grounded Anthropic call and renders a copy-only, save-nothing Foundation Document draft, labeled a draft toward the Foundation Document (never "seed"). D1–D7 are unchanged. The scoping-note reference moves from v0_2 to v0_3 (D8 folded there); the Handoff-must-report list gains the feat-example-generator branch state and a draft-surface-persists-nothing confirmation. (v0.1 is kept byte-intact as the superseded prior.)

Plain-language summary

Build a page on the Loomworks marketing site where a prospect types a few sentences about their own work and gets back an HTML "here's how Loomworks would help you" page. Behind it, a Cloudflare Worker makes two AI calls — first it maps their work into Loomworks's vocabulary, then it generates a tailored illustration grounded in that mapping. The AI is grounded in the glossary so it uses the terms correctly. Nothing real is created, nothing is saved, and the API key lives only in the Worker — never in the browser. Seven example chips, spanning very different kinds of work (including an architecture decision record for developers), let a visitor start with one tap.

What is built

A static page on loomworks-marketing (Cloudflare Pages) plus a Cloudflare Worker, same-origin, that exposes two AI endpoints. The page gathers a short seed-spine input, the Worker runs a two-step chained Anthropic call grounded in the glossary, and the page renders the resulting HTML. Ephemeral — no persistence, no engine, no engagement.

Hard constraints (non-negotiable)

• The API key never reaches the browser. It is a Cloudflare Worker environment secret. The page calls the Worker; the Worker calls Anthropic. No key in any client-served file.
• No engine surface. This calls no Loomworks engine route, creates no engagement, commits no seed. It is illustrative only.
• No persistence. Nothing is saved, logged, submitted, or catalogued. Output retention is client-side only (copy / download / print).
• Vocabulary fidelity. The illustration must use Loomworks terms as the glossary defines them. The system prompt is the instrument; do not let the model invent its own meanings for Memory, assertion, consideration, etc.

D1 — Input (seed-spine fields)

Three required short fields plus one optional, each with a worked placeholder:

• What is the work? (placeholder: e.g. "Producing a hikers' guide to our regional trails")
• Who is it for? (placeholder: e.g. "First-time hikers and our search-and-rescue volunteers")
• What does 'done' look like? (placeholder: e.g. "A published guide, kept current each season")
• Any constraints? (optional) (placeholder: e.g. "Must be accurate on water sources and hazards")

Keep it to these. This is a teaser, not an induction.

D2 — The seven example chips

Each chip, when tapped, pre-fills the D1 fields with a short worked seed for that domain. Chip text adapts the glossary's worked examples. The seven, with their pre-fill seeds:

1. Legal matter — work: Building the case record for Acme v. Beta, a breach-of-contract dispute. / for: The litigation team and outside counsel. / done: A complete, citable case record ready for filing. / constraints: Every fact tied to its exhibit or ruling.
2. Clinical-trial protocol — work: Drafting the protocol for a Phase II trial of a new therapy. / for: The research team, the IRB, and the regulator. / done: An approved protocol with every criterion justified. / constraints: Inclusion/exclusion criteria must be defensible.
3. Research synthesis — work: Synthesizing the evidence on a treatment's effect at 12 weeks. / for: A systematic-review panel. / done: A defensible synthesis, every claim sourced. / constraints: Retracted sources must be flagged and excluded.
4. Product specification — work: Specifying a new authentication system for our app. / for: The engineering and PM teams. / done: A spec engineers can build from without ambiguity. / constraints: Security requirements are hard rules, not suggestions.
5. Regulatory filing — work: Preparing our quarterly disclosure to the regulator. / for: The compliance team and the regulator. / done: A filing approved by the compliance lead. / constraints: Nothing filed without the compliance lead's approval.
6. Documentary — work: Building the factual and continuity record for a feature documentary. / for: The director, editors, and fact-checkers. / done: A locked record the edit can rely on. / constraints: Every claim on screen must be sourced and cleared.
7. Architecture decision record (ADR) — work: Keeping the record of why our system is built the way it is. / for: Current and future engineers on the team. / done: Any engineer can find why a decision was made, what it was weighed against, and what later changed it. / constraints: When a decision is reversed, the original and the reversal both stay visible.

The ADR chip's seed leads on the "why did we decide this" hook deliberately — it is the software chip and should land the recall-and-provenance point.

D3 — The grounding system prompt

A single system-prompt constant in the Worker, grounding the model in Loomworks's vocabulary, drawn from the glossary. It must teach:

• The four rooms in order: Memory (knowledge accumulates with provenance; additive; corrections kept alongside what they correct), Manifestation (committed Memory organized and frozen as a versioned snapshot, model-proposed and Operator-confirmed), Shaping (that snapshot arranged for a specific reader), Rendering (producing the artifact or the spec a downstream system consumes).
• The lifecycle vocabulary: engagement (candidate → active), assertion (the atom of Memory), held vs committed, provenance, consideration (deliberation closed with a verdict), cadence (a recurring prompt that brings Memory forward), relationship (typed link between assertions).
• The authority posture: the Operator decides and approves; the system surfaces and signals rather than acting on its own; irreversible actions expect confirmation.
• The plain-terms discipline: use these terms plainly; never invent alternative meanings; do not leak implementation or schema shorthand.
• What recall is: the real value is not just not-forgetting but recall — finding the relevant thing, knowing what links to what, noticing when a premise changed.

Draft the exact prompt text against loomworks-api-glossary-v0_3 and surface it in the handoff for review before first use. Embed it as a constant (no runtime glossary fetch).

The two-step chain (D7 — both at launch)

Call 1 — Analyze. User turn: the four D1 fields. The model returns clean <h3>-sectioned HTML mapping the prospect's work into Loomworks, with these five sections (D4):

1. <h3>Your work in Loomworks</h3> — the engagement framing
2. <h3>What its Memory would hold</h3> — assertions, provenance, kinds of contribution
3. <h3>Organizing and arranging it</h3> — Manifestation → Shaping for their readers
4. <h3>What you'd produce</h3> — Rendering: the artifact or the spec
5. <h3>Why this helps</h3> — recall, provenance, governed approval, in their terms

Call 2 — Illustrate. User turn: the original D1 fields plus the HTML analysis from Call 1. Instruct the model to generate a concrete worked illustration for this prospect's domain, citing its own prior analysis — a sample engagement showing what its Memory would hold (a few example assertions), what a Manifestation of it looks like, who Shaping would frame it for, and what Rendering would produce. Vary it; do not template it. Return sectioned HTML.

This chaining (the FORAY Business Analyzer pattern) is what makes the output bespoke. Both calls ship at launch.

D4 — Output rendering

• Call 1's HTML drops into a results region (innerHTML, the FORAY pattern — the model is instructed to emit only the <h3>-sectioned body, no document scaffolding).
• Call 2's illustration renders below it.
• Retention affordances: copy, download (the composed HTML), print-to-PDF (window.print() over the composed page). No other output path.

D5 — Wiring (Cloudflare Worker, same-origin)

• The page lives in loomworks-marketing (Cloudflare Pages).
• A Cloudflare Worker bound to the Pages project serves the two endpoints (e.g. /api/analyze, /api/illustrate) at the same origin as the page — no separate domain, no proxy hop, no CORS handling needed for same-origin.
• The Anthropic API key is a Worker environment secret (wrangler secret), read at request time. Never in any static asset.
• Confirm the current Anthropic model string at build — do not copy FORAY's pinned claude-sonnet-4-... verbatim; check what is current and use that. A fast model is appropriate for a marketing illustration.
• Body-size cap and input length limits on both endpoints (mirror FORAY's 1 MB / 5000-char order of magnitude).

Rate-limiting (the one item the scoping note left for the CR to specify)

This is a public, unauthenticated endpoint spending API credits — it must not be open to abuse. Implement at least:

• A per-IP rate limit at the Worker edge (Cloudflare's rate-limiting binding or a simple KV/Durable-Object counter) — a small number of generations per IP per hour (propose 10/hour/IP; confirm the number in the handoff).
• A global circuit-breaker — a daily cap on total generations across all visitors, so a coordinated abuse run cannot run the bill unbounded. Propose a conservative daily ceiling; surface it for Operator confirmation.
• Reject oversized inputs before calling Anthropic.

Surface the chosen limits in the handoff; the Operator confirms the numbers.

D8 — The take-away (a Foundation Document draft)

Source. Scoping note v0.3, D8 ("The take-away: a Foundation Document draft"). Added scope on top of D1–D7. This section is the only build surface this CR update introduces; D1–D7 are unchanged.

What is built. After an example has been generated and rendered (D4), the page offers the prospect a second, optional output: a Foundation Document draft — the prospect's own four answers (D1 seed-spine fields) written into the shape an engagement starts from, presented as plain text the prospect can copy and carry away.

D8.1 — Trigger (a separate action, not a sixth output section)

• The draft is produced by a separate prospect-triggered action, not as part of the analyze→illustrate chain (D7) and not as an additional section of the D4 output render.
• The trigger surfaces only after an example exists — you cannot draft from nothing. Before an example is generated, the action does not appear on the page (per the "only show what is available" constraint; no disabled control).
• Suggested surface: a control beneath the rendered example, labeled in plain terms (e.g. "Show a Foundation Document draft"). Exact label is stylistic; CC chooses under the plain-terms voice principles.

D8.2 — Generation (a third chain call, grounded)

• Triggering the action issues a third Anthropic call, separate from the two-step analyze→illustrate chain (D7). It takes the prospect's confirmed D1 inputs plus the analysis already produced, and emits Foundation-Document-draft-shaped text.
• The call is grounded on the same glossary vocabulary the D3 system prompt uses. The draft must use the methodology nouns (Memory, Manifestation, Shaping, Rendering) consistently with what the seed commits them to mean — the same grounding discipline D3 applies to the illustration.
• Guarantee-in-code, not prompt-trust (bridge note §2). The draft is not asserted to be induction-ready, and the build must not promise seed-format conformance (R-A5–R-A11) that it enforces only by asking the prompt nicely. The draft is starting material; the real Foundation Document is made downstream in create-engagement, where induction runs. The output-shape validation that D7 applies to the chain applies here too: validate that the third call returned the agreed draft structure; on failure, surface a plain recovery message, do not render a malformed draft.

D8.3 — Rendering (copy-only text area, save-nothing)

• The draft renders into a read-only text area with a Copy control. No download-as-named-file, no server round-trip that persists, no account, no commit.
• "Nothing is saved" (D6 / hard constraints) holds without exception: the draft is generated, rendered to the text area, and copied by the prospect to their own clipboard. The page persists no artifact and creates no engagement.
• The prospect pastes wherever they choose — an editor, notes, or as the opening message of a real engagement inside Loomworks. The page does not route them anywhere; the carry is the prospect's, by clipboard.

D8.4 — Labeling (the honesty-guard invariant)

• Every surface that presents this output calls it a draft toward the engagement's Foundation Document (or equivalent qualified phrasing). It never says "seed" — "seed" is a methodology noun, out of place on a public marketing surface, and "Foundation Document" is its plain-English name.
• The qualifier is the invariant: the surface must convey that this is a draft / starting point, not a finished Foundation Document, so a prospect who pastes it into create-engagement expects to keep working, not to be done. The wording of the qualifier is stylistic and may be tuned; the presence of a qualifier is not optional.
• Operator residual (carried from scoping note v0.3, D8). The default qualifier is "a draft toward the engagement's Foundation Document." If the Operator elects the shorter "Foundation Document draft" or the bare "Foundation Document," CC applies the Operator's choice; absent a choice, the default qualified form stands. The bare unqualified "Foundation Document" reintroduces the honesty concern and is the one form CC does not adopt without explicit Operator direction.

D8.5 — Open question for CC at build time (the pre-D8 branch)

Session memory (not the record) reports a D1–D7 build on loomworks-marketing branch feat-example-generator (78f9cda), unpushed and undeployed, predating D8. At build time CC confirms against the marketing repo whether that branch exists:

• If it exists: D8 is the delta added on top of it — the trigger (D8.1), the third call (D8.2), the text-area render (D8.3), and the labeling (D8.4). D1–D7 are not rebuilt.
• If it does not exist: D8 is built as part of the full D1–D8 implementation this CR specifies.

Either way D8's surface is the same; only whether D1–D7 are already present differs. CC reports the branch state in the Handoff-must-report return.

D8 — Acceptance

• The Foundation Document draft action appears only after an example is rendered; never as a disabled control.
• Triggering it produces glossary-grounded draft text in a read-only text area with a working Copy control.
• The page persists nothing and creates no engagement when the draft is generated or copied.
• Every surface presenting the draft carries the draft-not-finished qualifier and never uses the word "seed."
• The third call's output is shape-validated; a malformed return surfaces a plain recovery message rather than rendering.

Build sequence

1. Scaffold the page in loomworks-marketing — the D1 fields, the seven chips, the results region, the copy/download/print affordances. Static, no AI yet.
2. Stand up the Worker with the two endpoints, the system-prompt constant (drafted from the glossary), the model string, body/length caps, and the rate-limiting. Key as a secret.
3. Wire the page to the Worker; implement the two-step chain client-side (Call 1, hold its HTML, Call 2 with that HTML appended).
4. Test end-to-end against each of the seven chips and a free-typed input; confirm the key never appears in any client asset or network response; confirm rate-limiting fires.
5. Confirm always-on behavior (the Worker serves with the M4 off — it is edge-hosted, not tunneled).

Acceptance

• The page renders on the marketing site with the four D1 fields, seven working chips, and the three retention affordances.
• Each chip pre-fills the D1 fields; a free-typed input also works.
• The two-step chain runs: analyze returns five-section HTML; illustrate returns a domain-specific worked example grounded in the analysis.
• The API key appears in no client-served file and no response body — verified by inspecting the deployed assets and network traffic.
• Rate-limiting fires at the per-IP limit and the global cap; oversized inputs are rejected pre-call.
• The generator works with the M4 powered off (edge-hosted, always-on).
• No engine call, no persistence, nothing saved anywhere.
• The drafted system-prompt text and the chosen rate-limit numbers are surfaced in the handoff for Operator review.

Out of scope

• Persistence, harvesting, a library of generated examples (a separate later decision with privacy weight).
• Any engine integration or real seed/engagement creation.
• The Operator Layer and engine repos.
• The Phase 3 API documentation grind (a separate track).

Handoff must report

• The deployed page URL and the Worker route(s).
• The drafted system-prompt text (for review against the glossary).
• The confirmed model string.
• The chosen rate-limit numbers (per-IP and global daily).
• Confirmation the key is absent from all client assets and responses.
• Confirmation of always-on behavior with the M4 off.
• The feat-example-generator branch state (per D8.5) — whether the D1–D7 build existed and D8 was added on top, or D1–D8 were built together.
• Confirmation the D8 draft surface persists nothing and creates no engagement.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Example Generator — change request — v0.2 — 2026-06-11