Loomworks Example Generator — change request — v0.1

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

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.

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.

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