Version. 0.21
Date. 2026-07-17
Author. Claude.ai, on Operator direction.
Target. /Users/dunin7/loomworks-marketing. Cloudflare Pages project. New chain under functions/api/sales/; new Astro page. The existing Example Generator is not touched.
Technical consumer. Claude Code on DUNIN7-M4.
Status. Build specification for a disposable spike. Filed as CR-2026-152 — confirmed next-free against the record's highest existing numbered CR (CR-2026-151, change-requests/cr-2026-151-dismiss-not-recognized-v0_1.md) at filing time (2026-07-16).
Companion to. Example Generator CR v0.2 (D1–D8, the public generator), scoping note v0.3, sales-perspective mockup v0_2.
Change from v0.1. Section 8 (Access) only. The Operator settled the access decision v0.1 left open: the spike sits behind Cloudflare Access from the first deploy, reachable from the web, not local-only. Section 8 is replaced entirely — the Access application's scope (page + API routes, no wider), the dashboard-only-configuration limitation, and the Operator-owns-policy-membership boundary are now specified. No other section changes. (v0.1 is kept byte-intact as the superseded prior.)
Change from v0.2. Section 4.2 only. The step-3 fabrication audit (2026-07-16, perishables input) disproved this section's completeness claim: the check panel was stated to be "complete by construction," and two rendered specifics with no corresponding finding — found in the systems-lead column on the same run that produced a clean owner column — show it is not. Section 4.2 is replaced entirely: the check panel is still filtered from source, still computed not generated, but the completeness claim is retracted and the panel's real scope (complete with respect to findings, not with respect to prose) is stated instead, with the audit's two quoted specifics as evidence. The prior, now-corrected claim is preserved below the correction rather than deleted. No other section changes. (v0.2 is kept byte-intact as the superseded prior.)
Change from v0.3. Section 10 only. Acceptance criterion 4 still carried the completeness claim that section 4.2 retired in v0.3; corrected. This was specified during the v0.3 amendment and did not land. No other section changes. (v0.3 is kept byte-intact as the superseded prior.)
Change from v0.4. Sections 3.1, 3.2, and 5. The four reader archetypes (owner, ops lead, food safety/audit, systems lead) were perishables-specific and hardcoded; an Operator test on legal work produced columns shaped for readers that did not exist in that scenario. Readers are now derived from the work: analyze's output gains a readers array (§3.1), and the page becomes two-phase — an empty, generic ask; then, only after analyze returns, a reader section populated from what it proposed (§5). §3.2's example carried a hardcoded perishables reader ("reader": "owner", a margin-and-dock-level rationale) and was made reader-agnostic — the only concrete shape example in the CR, and a build session reads examples as intent. No other section changes. (v0.4 is kept byte-intact as the superseded prior.)
Change from v0.5. Section 3.1 only. v0.5 introduced derived readers but said only "readers" without specifying which kind — the legal test that followed derived readers of the prospect's own work product (lead trial counsel, litigation paralegal, testifying expert) rather than readers of the sales material itself. The tool produced feature illustrations of how the prospect's work would be shaped, not pitches for the prospect to buy the tool — collapsing this spike into what the public Example Generator already does. Section 3.1 now specifies which readers are meant, immediately after the readers array structure: decision-makers and influencers at the prospect organization, not roles inside the prospect's own work; observations about the prospect's own work-product readers belong in findings, not readers. Prompt posture is rewritten accordingly. Follow-on for next build, not done here: §5's reader-section subtitle was written before this correction and will need a matching update — noted, not edited, since this amendment is scoped to §3.1 only. No other section changes. (v0.5 is kept byte-intact as the superseded prior.)
Change from v0.6. Section 4.1 only. The contrast definition intersected foregrounded with cut, which reported no contrast on pairs differing on a third of the findings — measured on two real pairs, 0 narrow against 5 broad, and 1 narrow against 9 broad. The computation was correct; the definition was too narrow. Corrected to report both tiers. No other section changes. (v0.6 is kept byte-intact as the superseded prior.)
Change from v0.7. Section 3.3 only. Render's constraints did not forbid Loomworks internal vocabulary or invented illustrations; a legal run surfaced both. Section 3.3's prompt posture gains two additional constraints: no Loomworks internal vocabulary (the "Operator" role name must not appear in prospect-facing prose), and no invented illustrations (render may not manufacture example scenarios, hypothetical timelines, or named incidents that trace to no finding). Both are observed defects from the 2026-07-16 legal run, both are prompt-enforced and therefore soft per section 7. No other section changes. (v0.7 is kept byte-intact as the superseded prior.)
Change from v0.8. Section 3.1 only. v0.8 constrained render against Loomworks internal vocabulary but not analyze; a playbook run produced a finding whose claim text contained "Operator", which the panels then displayed verbatim to a prospect-facing surface. Section 3.1's prompt posture gains a matching constraint: a finding's claim text is displayed verbatim by the contrast and check panels, not paraphrased the way render paraphrases, so "Operator" and other Loomworks internal vocabulary must never appear in a finding. Observed 2026-07-16: a finding read "The commercial legal team lead or General Counsel is the Operator who must confirm each new version" — render correctly paraphrased it away, but the panels displayed it verbatim. This is the same class of guarantee as render's v0.8 constraint, not a stronger one — prompt-enforced and therefore soft, per section 7. No other section changes. (v0.8 is kept byte-intact as the superseded prior.)
Change from v0.9. Section 7 only. Reader-set non-determinism observed during the acceptance run. Section 7 gains a new item: analyze proposes readers by sampling, so the same four fields can produce a different room on a second run — an acceptance run on the playbook input derived a reader set that did not include the Chief Scientific Officer proposed by an earlier run on the identical input, while shape's partition arrays reproduced byte-identical across independent runs on a stored analysis. Not addressed here; noted as a question for the Operator Layer build. No other section changes. (v0.9 is kept byte-intact as the superseded prior.)
Change from v0.10. Section 5 only. Two corrections. First, section 5 specified side-by-side columns, following the mockup's layout — but the mockup made side-by-side look readable only because its reader texts were short hand-written blurbs; real rendered output runs to six paragraphs per reader, and the Operator reported the columns unreadable when judging acceptance criterion 2. Both the reader cards and the rendered readers were specified as grids against the mockup's short hand-written text; both fail on real derived content, so both are replaced with a stacked sequence — one full-width block per reader in the order checked; the comparison work moves to the contrast panel, where it is computed rather than left for the Operator to spot across narrow gutters. Second, section 5 specified the output surface but no way to take the output off the page; the Operator cannot carry a reader's version into a room. Section 5 gains a new subsection, "Taking the output off the page": a per-reader Copy control (plain text, one reader's prose, no page furniture), and a run-level Download control (one HTML file — four inputs, every rendered reader, the computed contrast panel, and the check panel verbatim, including its incompleteness statement, so the fabrication-risk flag travels with the prose it flags). Neither persists — clipboard action and client-side blob only, same posture as the rest of the page. No other section changes. (v0.10 is kept byte-intact as the superseded prior.)
Change from v0.11. Sections 3.3, 4.2, 5, and 10 — a pitch mode is added. The output carried reader-specific columns but no general overview: nothing the Operator says before getting specific to a room. The pitch is a general overview and opportunity, not shaped for any one reader — it runs through shape and render like a reader, but with fixed rules that are structural rather than domain-specific (forward: what the work is, what is hard about it, what becomes possible; cut: role-specific operational detail). It goes through shape so its selection is recorded and auditable and the check panel can scope to it — but it is not a reader: it does not appear in the reader list and does not participate in the contrast panel, which compares readers. The honesty constraint is the point of the pitch: an opportunity is a gap between where the prospect is and where they could be, and the pitch is the highest-fabrication-risk surface in this tool because its genre invites exactly a manufactured "before". Therefore its claims about the prospect's present state must trace to findings with source "input" — what they told the Operator, not what the model guessed; claims about what Loomworks does may draw on any finding; where the input does not establish where they are today, the pitch says what Loomworks does with work of this kind and manufactures no before. No superlatives, no transformation language, no invented pain. Prompt-enforced and therefore soft, per section 7. §3.3 adds the pitch mode; §4.2 extends the check panel to the pitch's inferred findings; §5 places the pitch first, above the rendered readers, with its own Copy control, inclusion in the Download, an explicit on-by-default control separate from the reader list and absent from the fan. §10's acceptance gained a criterion for the pitch (read aloud to the prospect, surviving their corrections), and its criterion 2 still said "columns" after v0.11 replaced them with stacked rendered readers — corrected. No other section changes. (v0.11 is kept byte-intact as the superseded prior.)
Change from v0.12. Section 7 only. The pitch's honesty constraint held on first exercise, and the audit surfaced where its boundary actually sits. Section 7 gains a new item: exercised 2026-07-17, the pitch made no claim tracing to nothing, manufactured no "before", and used no superlative or transformation language — but three inferred claims reached the prose by being scoped to the work-kind rather than the prospect ("a playbook of this kind", "likely", "may be"), within the letter of §3.3a's rule, and one of them reads in a room as a diagnosis of the prospect despite its generic framing. Not tightened — recorded so the boundary is known rather than assumed; the check panel's listing of these claims is the intended containment. No other section changes. (v0.12 is kept byte-intact as the superseded prior.)
Change from v0.13. Sections 3.3, 4.2, 5, and 10 — a Foundation Document draft is added. The output had no closing artifact: nothing the Operator leaves behind. A Foundation Document names what an engagement is committed to, and there is one engagement — the prospect's work — regardless of who is in the room, so the draft sits outside the reader axis: one per run, not one per reader, absent from the reader list and the contrast panel. §3.3 gains subsection 3.3b — the draft runs as a render over the findings with no shape step (it describes the work, it does not select material for someone), and its honesty constraint is sharper than the public Example Generator's because the Operator, not the prospect, wrote the four fields: findings with source "input" become commitments (the prospect stated these), findings with source "inferred" become open questions in a "still to work out" section (the model inferred them; the prospect has not confirmed them). It is labeled "a draft toward the engagement's Foundation Document", carries the D8.4 qualifier, and never uses the word "seed". §4.2 extends the check panel to the draft's inferred findings; §5 renders the draft last, below the rendered readers, with its own Copy control, inclusion in the Download, and an explicit on-by-default control separate from the reader list and absent from the fan; §10 gains a criterion (commitments trace to entered input, inferences appear as open questions). Prompt-enforced and therefore soft, per section 7. No other section changes. (v0.13 is kept byte-intact as the superseded prior.)
Change from v0.14. Sections 5 and 3.1 — wording only. The surface called the readers "the room", a phrase carried from the mockup when readers were four fixed archetypes invented for a single meeting. Derived readers span organizations and are reached separately — in a meeting, by a forwarded document, or in a procurement review weeks apart (observed 2026-07-16: one run derived readers at two different organizations) — so the metaphor over-specifies a meeting that does not happen and does not say what the readers are. §5 gains "The readers are not 'the room'": the surface asks "Who do you need to convince?", the hero heading, lede, and review banner drop "room", and the banner says the draft is not for the prospect until the Operator has read it. The reader question must also hold its distance from the four fields' "Who is the work for?" — a different question, and conflating them is what produced work-product readers in v0.5. §3.1's prompt posture, which described the readers as "the room the Operator is walking into", gets the same wording alignment; the readers derive well as they stand, so this is not a behavioural change. No other section changes. (v0.14 is kept byte-intact as the superseded prior.)
Change from v0.15. Section 3.3b only. The draft's honesty constraint leaked on first exercise. The v0.14 build partitions the findings by source server-side but hands the model both lists and asks it to respect the labels — prompt-enforced, and exercised 2026-07-17 it did not hold: two passages reached the commitments section from inferred findings, both Loomworks's own versioning and provenance value proposition (version history, supersession dates, approval authority legible in the artifact), presented to the prospect as their own commitment, and the same run put approval authority as a settled commitment in one section and an open question in the other. Corrected to a structural split: the draft is now two render calls, not one — a commitments call that receives only source "input" findings, an open-questions call that receives only source "inferred" findings, and a server that composes the two into one draft. The input-to-commitment boundary becomes structural rather than requested — a model not handed the inferred material cannot write it into the commitments, the same principle as shape emitting only finding ids. It does not fix within-section fabrication (section 7's standing limit, unchanged); what is now guaranteed is that no inferred finding reaches the commitments section. No other section changes. (v0.15 is kept byte-intact as the superseded prior.)
Change from v0.16. Section 7 only. The two-call split held on first exercise; the residual within-section risk was observed once during wiring. Section 7 gains an item recording it — the commitments call can still fabricate within its own section (a synthetic run produced one such commitment; the real biotech run produced none) — alongside a new item that nothing verifies the prose against the findings: every fabrication this build found was found by hand audit, so the fabrication surface is unmonitored, not merely unfixed, which is the largest gap in the design. The source-field item is amended — three guarantees now route through analyze's own source classification (the check panel, the pitch's present-state constraint, and the draft's two-call split), making that model judgement the design's load-bearing weakness. The latency item is amended with measured figures (analyze 24–56s, shape 4.2–13.1s, render 12.8–21.5s, about 49s for a two-reader run; the 183s outlier did not recur) and the note that the pitch and draft now make four render-class calls where one was planned, with no target set. No other section changes. (v0.16 is kept byte-intact as the superseded prior.)
Change from v0.17. Sections 6 and 8. Rate limiting was listed in section 7 as an inherited caveat; it is a deployment blocker, and section 8 (Access) now names it as one: the limiter keys on IP-and-hour and on day with no route, so this spike and the public Example Generator share one pool, and the caps — set at f2dc67f for a two-call generator — allow only two eight-request sales runs per hour before an Operator is locked out mid-run, and roughly twelve per day globally, taking the public marketing page down with them for the rest of the day. Re-sizing (separate counters by route family, raised caps, or both) trades against Anthropic spend and is an Operator decision, named not solved. Section 6 gains two failure findings from exercising the pitch and draft paths, which did not exist when the failure work was first done: the draft's commitments and open-questions calls run under Promise.all and fail together (a commitments failure discards a successful open-questions result), and the in-block failure message calls every surface — including the pitch and the draft — a reader. No other section changes. (v0.17 is kept byte-intact as the superseded prior.)
Change from v0.18. Sections 2, 6, and 8. The rate-limit deployment blocker is resolved and the in-block failure copy is corrected. §8's "must be re-sized before this deploys" item is replaced: the spike no longer shares the public generator's limiter pool but carries its own in functions/api/sales/_lib.js, keyed rl:sales:*, on the same RATE_LIMIT_KV binding, with Operator-set caps of 120/hour/IP and 400/day (fifteen runs/hour, fifty/day at eight requests per run); the public generator's 20/hour and 100/day are unchanged, and fail-open is retained (settled by Operator direction 2026-07-17). §2 gains the one permitted exception to not modifying the shared functions/api/_lib.js: the spike does not use its rate limiter, calling the spike-local one instead — the shared file is still not edited. §6's failure item is corrected: each failed block now names its own surface (the pitch, a named reader, or the Foundation Document draft) rather than calling every surface a reader. No other section changes. (v0.18 is kept byte-intact as the superseded prior.)
Change from v0.19. Sections 3.3, 4.2, 5, and 10 — a leave-behind is added. The output had nothing the Operator leaves with the prospect: the pitch is what is said, not what is left behind. §3.3 gains subsection 3.3c — one per run, not one per reader; a structured one-pager that does not go through shape (it is not an argument selected for someone, it is the case) and does not appear in the reader list or the contrast panel. Two of its six sections make claims about the prospect's present state and about other people's products, and neither is knowable from four sentences: every fabrication this tool has produced was the model inventing a present state (the step-3 audit, §4.2, is the record of it), and a competitor claim drawn from training data is worse — possibly stale, framed as fact, to someone who uses the product daily. Three new inputs are added, all optional, all Operator-supplied, all in phase one: how the prospect does this today as far as the Operator knows, who else they are considering and what the Operator knows about how it works, and what the Operator wants to happen next. Enforced in code, not the prompt: the leave-behind is two render calls. The first — sections 1, 2, and 4 — receives the findings, claims about the prospect's situation held to the pitch's source constraint (§3.3a). The second — sections 3, 5, and 6 — receives only the three new inputs and Loomworks's own description of what it does; no inferred findings are in its context, so it cannot invent a current state or a competitor because neither is available to it. If all three inputs are empty, the second call does not run and its sections are absent, not placeholdered. The table compares approaches, never products: a named vendor's approach is only describable from what the Operator supplied about it. §4.2 extends the check panel to the leave-behind's inferred findings, noting the second call contributes none by construction. §5 places the three new inputs in phase one below the four, as an optional group feeding the leave-behind; the leave-behind is an explicit control, on by default, separate from the reader list and absent from the fan, rendering after the readers and before the Foundation Document draft — the pitch is what is said, the readers are the arguments, and the two leave-behinds close: the case, then the starting point for the work. The draft's own description is corrected to match, since it no longer stands as the only artifact of that kind. The leave-behind carries its own Copy control and is included in the Download. §10 gains an acceptance criterion: with the three inputs empty, sections 3, 5, and 6 are absent rather than invented; supplied, every claim about the prospect's present state and any named alternative traces to what the Operator entered. No other section changes. (v0.19 is kept byte-intact as the superseded prior.)
Change from v0.20. Section 3.3c only. Exercised 2026-07-17 on the biotech supplier-agreements scenario: the leave-behind's two-call split held completely against inventing a competitor's facts — the named-alternative column read "Not known from what was shared" on every cell, five times, the highest-risk cell in the design — but leaked on the prospect's own current state inside the comparison table, in four of five rows: two extrapolated from what the Operator entered, two invented outright (an obligation-tracking row and a who-holds-the-record row, neither mentioned at all). The mechanism was the table's rows, not the prompt: the model chose which dimensions to compare from what Loomworks does, and every row it invented then demanded a current-approach cell it could not source, so it wrote one rather than leave a gap. §3.3c gains a new passage after the two-call description: each row must now be a dimension the Operator actually described — sourced by construction, because the row exists only because the Operator described it — not a dimension the model selected from Loomworks's own capabilities; a row with no sourced current-approach cell does not exist, the same principle as the two-call split itself and as shape emitting only finding ids. The existing "the model frames the comparison; it does not source it" sentence is corrected to match, with a "Prior position, corrected" note — the model was never meant to be sourcing product claims (that held), but it was still framing which dimensions existed, and that framing is exactly what leaked. Not a prompt tightening: the freedom to choose a row is removed, not asked to be used more carefully. No other section changes. (v0.20 is kept byte-intact as the superseded prior.)
The Example Generator asks four questions about a prospect's work and produces one example. This spike adds a fifth question — who is going to read this — and produces one artifact holding a version per reader, side by side.
It is not a variant of the existing generator. The existing chain writes finished prose in its first call, which means there is nothing left to shape afterwards. This spike replaces that with a chain that finds the material first, selects from it per reader second, and writes prose last. That is the only way the fifth question can do real work rather than re-tone the same document.
The spike is disposable. It exists to answer one question: does one analysis genuinely shape differently per reader, or does the model just re-word the same thing? If the answer is yes, the real build goes in the Operator Layer. If no, delete the spike.
analyze.js emits a five-section HTML fragment — finished prose, written for a generic reader. By the time it returns, the selection has already happened: it chose what to say and what to omit, for nobody in particular.
Hand that output to a shaping call and instruct it to address the owner, and the model has two available moves: re-word what survived, or invent material that was never there. Re-toning or fabricating. Neither is Shaping.
This was confirmed by inspection of both models' output on the same input (2026-07-16, perishables). Sonnet's analyze is good prose and has still discarded the structure. The material that makes the strongest case — an unmatched balance of stock, a negotiation trajectory — appears only in illustrate, downstream of where shaping would have to happen.
The lesson applied: a guarantee is enforced in code, not requested in a prompt. Asking a shaping prompt to "select rather than re-tone" cannot work when the upstream call has already thrown the selectable material away. The fix is architectural.
A parallel chain under /api/sales/, and one new page. Four new files:
| File | Route | Role |
|---|---|---|
| functions/api/sales/analyze.js | POST /api/sales/analyze | Four fields → structured findings. No prose. |
| functions/api/sales/shape.js | POST /api/sales/shape | Findings + one reader → a selection over finding IDs. No prose. |
| functions/api/sales/render.js | POST /api/sales/render | Selection + findings → prose for that reader. |
| src/pages/sales-generator.astro | /sales-generator/ | The page. |
functions/api/_lib.js is reused for the Anthropic caller, rate limiting, input caps, and sanitisation. It is not modified — the public generator depends on it. If the spike needs a helper _lib.js does not have, add it to a new functions/api/sales/_lib.js rather than editing the shared one.
The one permitted exception to reusing the shared functions/api/_lib.js is that the spike does not use its rate limiter. functions/api/sales/*.js call a spike-local limiter in functions/api/sales/_lib.js instead (§8). The shared file is still not edited.
The existing analyze.js, illustrate.js, foundation-draft.js, and example-generator.astro are not touched.
analyze — find the material, write for nobodyInput. The four existing fields (work, audience, done, constraints), same 2000-char caps.
Output. Structured JSON. Not HTML, not prose.
{
"findings": [
{
"id": "f1",
"claim": "The window between grade-out and shrink is measured in hours",
"room": "memory" | "manifestation" | "shaping" | "rendering" | "why",
"source": "input" | "inferred",
"weight": "central" | "supporting"
},
...
],
"groups": [
{ "label": "What Memory would hold", "finding_ids": ["f1","f4"] },
...
],
"readers": [
{
"key": "short_stable_key",
"label": "The supervising partner",
"description": "One short line — what they are measured on",
"forward": "What this reader's version leads with",
"cut": "What this reader's version leaves out"
},
...
]
}
Which readers. These are the people who would read this sales material — the people whose buy-in the Operator needs at the prospect organization, reached however they are reached: in a meeting, by a forwarded document, or in a procurement review weeks apart. They are decision-makers and influencers: whoever holds the budget, whoever owns the operational pain, whoever must sign off, whoever assesses the risk. Derived from the domain, in that domain's vocabulary.
They are not readers of the prospect's own work product. For a legal matter, "managing partner" and "general counsel" are readers of this material. "Testifying expert" and "litigation paralegal" are not — they are roles inside the work, and a column shaped for them is a feature description rather than a pitch. The public Example Generator already illustrates how work is shaped for its own readers; that is not what this tool is for.
Where work-product readers belong. Observations about who reads the prospect's work, and what must not cross between them, are valuable — they are findings, not readers. That outside co-counsel must not receive privileged work product is ammunition inside a pitch to a managing partner, not a column of its own. analyze should surface such observations as findings with source "inferred".
The source field is the point of this whole design. input means the finding traces to something the Operator typed. inferred means the model produced it — the Brix number, the assumption that they run a WMS, the claim that they work off spreadsheets today. Every finding is one or the other, and the model must classify each one.
readers is derived, not fixed. Between three and five readers, proposed by the model in the vocabulary of the work it was just given — not the perishables set, not any fixed set. The model proposes; the Operator selects, at generation time, by checking the ones that apply. This replaces a hardcoded four-archetype set (owner, ops lead, food safety/audit, systems lead) that shipped in v0.1–v0.4 — see the Change-from-v0.4 note.
Prompt posture. Find everything worth saying. Organize it. Address nobody. Do not write prose. Emit only the JSON object. Propose the readers of the sales material itself — the decision-makers and influencers at the prospect organization who would read a pitch about adopting something like this, not the people who read or act on the prospect's own work. Grounded in the four fields, in that organization's vocabulary — not a generic template, and not the roles that already exist inside the work being described.
No Loomworks internal vocabulary in findings. A finding's claim text is displayed verbatim by the contrast and check panels — it is not paraphrased the way render paraphrases. Anything a finding says reaches the surface as written. "Operator" is this system's role name and must never appear in a finding; name the actual role in the prospect's world. The four rooms may be named in plain terms; codebase shorthand and internal role names may not. Observed 2026-07-16: a finding read "The commercial legal team lead or General Counsel is the Operator who must confirm each new version" — render correctly paraphrased it away, but the panels displayed it verbatim. This is prompt-enforced and therefore soft, per section 7. It is the same class of guarantee as render's, not stronger.
Validation. Reject if: not valid JSON, any finding missing a field, any finding_ids entry not matching a finding id, any source value outside the enum, zero findings, any reader missing one of its five fields, reader keys not unique, or reader count outside three to five. A malformed readers array fails the whole analyze response, exactly as a malformed findings array does. On failure, surface the plain recovery message (§6). Never render a malformed analysis.
shape — select, do not writeInput. The findings array and exactly one reader key.
Output. A selection over finding IDs. It cannot introduce text.
{
"reader": "<key from the readers array returned by analyze>",
"foregrounded": ["f3","f7"],
"included": ["f1","f4","f9"],
"cut": ["f2","f5","f6","f8"],
"rationale": "What this reader is measured on, and what is therefore not theirs to read."
}
The invariant, enforced in code: every ID in foregrounded, included, and cut must exist in the findings array, and the three lists together must partition it exactly — no ID in two lists, no finding unaccounted for. Reject otherwise.
This is what makes shaping structurally incapable of fabrication. The call selects from a fixed set. It has no field in which to invent.
One call per reader. N readers checked = N shape calls, issued in parallel. They are independent.
render — prose, from the selection onlyInput. One shape selection, plus the findings it references.
Output. HTML fragment for that reader's column. Sanitised via the existing sanitizeFragment before injection.
Prompt posture. Write for this reader using only the findings supplied. Lead with the foregrounded ones. Do not introduce facts that are not in the findings.
No Loomworks internal vocabulary. The reader is a stranger at the prospect organization. "Operator" is this system's role name and must never appear — name the actual person in their world, or say "your". The four rooms may be named in plain terms; codebase shorthand and internal role names may not. Observed 2026-07-16: a rendered column told a law firm's technology director to "wait for the Operator's confirmation."
No invented illustrations. Render may not manufacture example scenarios, hypothetical timelines, or named incidents that trace to no finding. Where a finding warrants an example, the example comes from what the Operator described. Observed 2026-07-16: a column invented a "deponent said on Monday, correction arrives on Friday" scenario with no source finding. This is prompt-enforced and therefore soft, per section 7 — it narrows the fabrication surface, it does not close it.
Note honestly: this last constraint is prompt-enforced, not code-enforced, and is therefore the weakest link in the chain. render is where new fabrication can still enter. This is a known limit of the spike, not a solved problem — see §7.
render runs in parallel per reader, following its shape call.
The pitch. A general overview and opportunity, not shaped for any one reader. It runs through shape and render like a reader, but with fixed rules that are structural rather than domain-specific:
It goes through shape so its selection is recorded and auditable, and so the check panel (§4.2) can scope to what reached it. It is not a reader: it does not appear in the reader list, and it does not participate in the contrast panel (§4.1), which compares readers. The pitch's shape call uses the fixed forward/cut rules above in place of a reader's per-reader rationale; its selection partitions the findings exactly as any shape call does, so it cannot introduce text (§3.2's invariant holds).
The honesty constraint — the point of the pitch. An opportunity is a gap between where the prospect is and where they could be. The model knows four fields; everything else about their present state is inference, and the pitch is the highest-fabrication-risk surface in this tool because its genre invites exactly that — a manufactured "before" that makes the opportunity look larger.
Therefore: the pitch's claims about the prospect's present state must trace to findings with source: "input" — what they told the Operator, not what the model guessed. Claims about what Loomworks does with work of this kind may draw on any finding. If the input does not establish where they are today, the pitch says what Loomworks does with work of this kind and does not manufacture a before.
No superlatives, no transformation language, no invented pain. Realistic means it would survive being read aloud to the prospect with them correcting it.
This is prompt-enforced and therefore soft, per section 7 — like render's no-invented-illustrations constraint, it narrows the fabrication surface, it does not close it. It is the same class of guarantee, applied to the surface where the genre pushes hardest against it.
One draft per run, not one per reader. A Foundation Document names what an engagement is committed to. There is one engagement — the prospect's work — regardless of who is in the room. Readers shape the argument for adopting it; they do not shape the work itself. The draft therefore sits outside the reader axis, does not appear in the reader list, and does not participate in the contrast panel.
It does not go through shape: it is not an argument that selects material for someone, it is a description of the work.
The draft is two render calls, not one.
The commitments call receives only findings with source "input". The inferred findings are not in its context. It writes what the engagement is committed to, from what the prospect stated.
The open-questions call receives only findings with source "inferred". It writes the "still to work out" section, phrased as questions to confirm.
The server composes the two into one draft.
Why the split rather than a stronger instruction. The single-call design partitioned the findings correctly and labeled both lists for the model, then asked it to respect the labels. Exercised 2026-07-17, it did not. Two passages reached the commitments section from inferred findings, and both were Loomworks's own versioning and provenance value proposition — version history, supersession dates, approval authority legible in the artifact — presented to the prospect as their own commitment. The model reached for the product's story and wrote it into the prospect's foundation.
The same run produced a direct contradiction: approval authority appeared as a settled commitment in one section and as an open question in the other, in the same draft.
A model handed material and told not to use it in one section will use it. A model not handed the material cannot. The split makes the input-to-commitment boundary structural rather than requested — the same principle as shape emitting only finding ids.
What the split does not fix. The commitments call can still fabricate within its own section — assert something in no finding at all. That is section 7's standing limit and is unchanged. What is now guaranteed is that no inferred finding reaches the commitments section.
The honesty constraint, which is sharper here than in the public Example Generator. There, the prospect writes the four fields and the draft reflects their own words. Here the Operator writes them, so the draft is a Foundation Document for the prospect's engagement built from the Operator's account of their work — and handed to the prospect as theirs.
Therefore:
source: "input" become commitments in the draft. The prospect stated these.source: "inferred" become open questions in a "still to work out" section. They are not asserted as commitments. The model inferred them; the prospect has not confirmed them.A draft with honest gaps invites the correction that makes it useful. A draft that asserts confidently invites the prospect to find the error and stop trusting the room.
Labeling. The output is "a draft toward the engagement's Foundation Document" and carries the qualifier per the public generator's D8.4. The word "seed" never appears — the draft travels to a prospect who has never heard it, and the tool being Operator-facing does not change what the artifact is.
This is prompt-enforced and therefore soft, per section 7.
One per run, not one per reader. A structured one-pager the Operator leaves with the prospect. It does not go through shape — it is not an argument selected for someone, it is the case. It does not appear in the reader list and does not participate in the contrast panel.
Its sections, in order:
Three new inputs, all optional, all Operator-supplied, all in phase one:
Why these are inputs and not inferences — this is the point of the whole subsection. Sections 3 and 5 make claims about the prospect's present state and about other people's products. Neither is knowable from four sentences.
Every fabrication this tool has produced was the model inventing a present state. The step-3 audit (§4.2, 2026-07-16, perishables input, systems-lead reader) is the record of it — with nothing in the four fields to license either claim, the model asserted that a prior system might be "storing a single current value" and that "the current workflow allows offers to go out from a live, mutable inventory view." Section 3 is that failure mode as a requirement.
Competitor claims are worse and differently wrong. A claim about another company's product is drawn from training data with a cutoff. "They probably use spreadsheets" is a guess the prospect can correct. "That vendor requires manual reconciliation" is a fact that may have been true once and false since, said to someone who uses it daily. A table makes it worse — a grid reads as authoritative, and one wrong cell discredits the rest.
Therefore, enforced in code and not in the prompt: the leave-behind is two render calls.
The first call — the Loomworks case. Sections 1, 2, and 4. It receives the findings. Claims about Loomworks may draw on any finding. Claims about the prospect's situation trace to findings with source "input", per the pitch's constraint in §3.3a, with the same soft limit.
The second call — the comparison. Sections 3, 5, and 6. It receives only the three new Operator-supplied inputs, plus Loomworks's own description of what it does. No inferred findings are in its context. It cannot invent a current state or a competitor because neither is available to it.
If all three new inputs are empty, the second call does not happen and sections 3, 5, and 6 are absent. Not placeholdered, not "not specified" — absent. Same rule as a tool the mint refuses: not shown, not disabled, gone.
The table's rows derive from the current-approach input. They are not chosen from Loomworks's capabilities.
Exercised 2026-07-17 on the biotech supplier-agreements scenario. The competitor column held perfectly — every cell for the named alternative read "Not known from what was shared," five times, on the highest-risk cell in the design. The model refuses when it knows it does not know.
The current-approach column leaked in four of five rows. Two were extrapolations from what the Operator entered; two were invented outright — an obligation-tracking row and a who-holds-the-record row, neither of which the Operator had mentioned at all.
The mechanism is the rows. The model chose them from what Loomworks does. Every such row then demands a current-approach cell the model cannot source, and it writes one rather than leave a gap. The prompt did not fail; the table's shape forced the invention.
Therefore: each row is a dimension the Operator described. The Operator says agreements sit in shared drive folders, amendments arrive by email, and renewal dates are tracked by memory — that is three rows. Each row's current-approach cell is sourced by construction, because the row exists only because the Operator described that dimension. Loomworks's cell is a claim about Loomworks and may draw on the findings. The named alternative's cell remains "Not known from what was shared" unless the Operator supplied it.
A row with no sourced current-approach cell does not exist. Not "not specified" — absent.
This is the same principle as the two-call split and as shape emitting only finding identifiers. A model given the freedom to pick the row will pick one it cannot fill honestly. Do not tighten the prompt; remove the freedom.
A thin description gives a thin table, and that is correct. If the Operator described one thing about how the prospect works today, the table has one row — and that is the signal to go and ask them, not to generate.
The table compares approaches, never products. "The spreadsheet-and-email approach" is a category claim, true by construction. A named vendor's approach is only describable from what the Operator supplied about it. Each row is sourced from what the Operator described, not framed by the model — the audit above is why. Same principle as FORAY's regulatory flags: Operator-selected, never model-inferred.
Prior position, corrected. Through v0.20, this section said "the model frames the comparison; it does not source it." That was half right: the model was never meant to invent a competitor's facts, and it did not — the audit above confirms it. But "frames the comparison" left the model free to choose which dimensions the table compared at all, and that freedom is exactly what leaked: a dimension the model picked from Loomworks's own capabilities, rather than from what the Operator described, forced a current-approach cell with nothing to source it from. The model does not frame the comparison. The Operator's description does.
The absence is useful. If the leave-behind cannot write section 3, the Operator does not know how the prospect works today — and that is the thing to ask them, not to generate.
Enforcement. The two-call split is code-enforced, the same principle as §3.2's partition and §3.3b's commitments/open-questions split — the second call's context cannot contain what was never given to it, so it cannot fabricate a current state or a competitor regardless of what the prompt says. The first call's claim about the prospect's situation rests on the same prompt-level source constraint as the pitch (§3.3a) and is therefore soft, per section 7, in exactly the same way and to exactly the same degree.
Both were hand-authored in the mockup. Neither should be.
Given two or more shape selections, the contrast is set arithmetic over finding IDs. No model call. If it can be computed it must not be generated — a generated contrast can claim a difference that is not there.
Two tiers are reported, because one alone misleads.
The sharp tier: foregrounded(A) ∩ cut(B). What one reader leads with and the other refuses. The strongest available signal, and rare — readers often share headline findings while differing underneath.
The broad tier: (foregrounded ∪ included)(A) ∩ cut(B). What A's document carries that B's does not have at all. This is the honest measure of how far two documents differ.
Both directions of both tiers. Where a direction is empty it is omitted, not placeholdered.
The panel leads with the broad tier. The sharp tier is reported when non-empty, marked as the stronger signal. Where both are empty in both directions, the two selections genuinely overlap and the panel says so plainly rather than manufacturing a difference.
Prior position, corrected. CR v0.1 through v0.6 defined contrast solely as foregrounded(A) ∩ cut(B). That definition was measured against two real pairs on 2026-07-16 and found to report 0 where 5 findings differed, and 1 where 9 differed. Both readers led with the same headline findings while their documents diverged substantially underneath — the narrow definition looks exactly where difference is not. It was not a computation error. It would have reported "no contrast" on pairs that differ by a third of the analysis, in a tool whose entire purpose is to show that difference.
source, and incomplete
Every finding where source === "inferred" and that survived into at least one rendered column is a specific the draft asserts about the prospect's business that came from the model, not from the Operator.
That list is the check panel. Filter, do not generate.
The panel is complete with respect to findings. It is not complete with respect to prose. render can introduce specifics that correspond to no finding. Those have no id and no source field, so the filter cannot see them, and no way of building the panel changes that — it audits what analyze guessed, not what render added on top.
This is not theoretical. The step-3 audit (2026-07-16, perishables input, systems-lead reader) found two such specifics in a single rendered column, both asserting things about the prospect's existing tooling that appear in no finding:
Both are hedged and neither invents a number or a named system. Both are assertions about how the prospect works today, produced by a model that was told nothing about how they work today. The owner column, on the same analysis, introduced nothing.
Therefore the panel must not claim completeness on the surface. It says what it is: the specifics the analysis inferred. It does not say or imply that it lists everything unverified in the output. The Operator reads the prose regardless — the panel narrows that job, it does not replace it.
The check panel covers the pitch's inferred findings alongside the readers'. The pitch's shape selection is recorded (§3.3a), so every finding with source === "inferred" that survived into the rendered pitch is filtered onto the panel exactly as a reader's are. The pitch carries the highest fabrication risk of any surface here — its genre invites a manufactured "before" (§3.3a) — and it is not exempt from the audit; its inferred specifics appear on the same list, scoped to what reached the pitch.
The check panel covers the draft's inferred findings too, alongside the pitch's and the readers'. The Foundation Document draft (§3.3b) renders over the findings without a shape step, so its inferred findings reach the panel by the same source filter. The draft already routes them into its "still to work out" section rather than asserting them as commitments (§3.3b); listing them here is the same audit applied to the same surface, not a second mechanism.
The check panel covers the leave-behind's inferred findings too, alongside the draft's, the pitch's, and the readers'. The leave-behind's first call (§3.3c) renders over findings the same way the pitch and the draft do, so any inferred finding that survives into it reaches the panel by the same source filter. The second call contributes none, by construction — it receives no inferred findings, only the three new Operator-supplied inputs and Loomworks's own description of itself, so there is nothing there for the filter to find.
Prior position, corrected. CR v0.1 and v0.2 stated at this section that the panel was "complete by construction — nothing inferred can reach the Operator without appearing on the list." That claim was false. It was contradicted within the same document by section 7, which already admitted render can fabricate, and it was disproven in practice at step 3 before the panel was built.
Follows sales-perspective mockup v0_2 for visual language; the flow itself is now two-phase, not the mockup's single-screen form. The mockup's four hardcoded readers are gone along with the fixed archetype set — see the Change-from-v0.4 note.
The readers are not "the room". The surface asks "Who do you need to convince?" — these are the people whose buy-in the Operator needs, deciders and influencers alike, reached in a meeting or by a forwarded document or in a procurement review weeks apart. Observed 2026-07-16: one run derived readers at two different organizations.
The phrasing also has to hold its distance from the four fields' "Who is the work for?", which asks who reads the prospect's work. That is a different question with a different answer, and conflating them is what produced work-product readers in v0.5. The reader question asks who reads this sales material.
Replace "room" in the surface copy. The hero heading, the lede, and the review banner carried "room" from the mockup, when readers were four fixed archetypes invented for a single meeting; the metaphor over-specifies a meeting that does not happen and does not say what the readers are. The hero heading asks "Who do you need to convince?"; the lede and the review banner drop "room" for the same framing. The review banner says the draft is not for the prospect until the Operator has read it.
analyze. Not automatic on blur, not on keystroke, not on a timer. The Operator decides when the call spends, every time.analyze's readers array. Each shows its own label, description, forward, and cut — the model's proposal for this specific work, not a fixed set.shape and render per checked reader, in parallel, exactly as now.shape and render alongside the readers' (§3.3a), in parallel.render — no shape, per §3.3b — alongside the pitch's, the leave-behind's, and the readers', in parallel.The reader cards stack too. Each proposed reader is a full-width row, not a cell in a grid: the checkbox and label, the one-line description, then its forward and cut rules at a readable measure. The mockup's grid held four hand-written one-line descriptions. Derived readers carry a description plus a forward rule plus a cut rule — several sentences each — and a two-up grid renders them as tall narrow stacks with ragged empty cells beside them.
The same correction as the rendered readers, for the same reason: the layout was specified against short placeholder text and does not hold real content.
The pitch renders first, above the rendered readers. It is the overview, and the Operator reads it before the role-specific versions — the general opportunity, then who in the room the specifics are for. It is a full-width block like the readers, but it sits at the top and is not one of them.
The rendered readers stack, one above the other, below the pitch, in the order they were checked. Each is a full-width block: the reader's label, then their prose at a readable measure. Not columns. Rendered output runs to several paragraphs per reader, and side-by-side reduces that to unreadable gutters.
The leave-behind renders after the readers, before the Foundation Document draft. The pitch is what the Operator says; the readers are the arguments; the two leave-behinds close — the case for them (§3.3c), then the starting point for the work (§3.3b). It is a full-width block like the others, sitting between the readers and the draft.
The Foundation Document draft renders last, below the leave-behind. It is the starting point for the work, read after the case has been made for it — the pitch opens, the readers argue, the leave-behind makes the case in a form the prospect keeps, and the draft is the thing the engagement would actually commit to. It is a full-width block like the others, but it sits at the bottom and is not one of them (§3.3b).
Prior position, corrected. Through v0.19, this section called the draft "what the Operator leaves behind," as if it were the only artifact of that kind. §3.3c adds a second, more literal one — a structured case the Operator physically leaves with the prospect. Both are leave-behinds now; the draft's role is recast as the second of the two, the starting point for the work rather than the case for it.
The comparison work moves to the contrast panel, which is where it belongs — it computes the difference rather than asking the Operator to spot it across two narrow columns. Section 4.1's two tiers already report what each reader's document carries that another's does not.
Prior position, corrected. CR v0.1 through v0.10 specified side-by-side columns, following the mockup's layout. The mockup made side-by-side look readable only because its reader texts were short hand-written blurbs; real rendered output runs to six paragraphs per reader, and the Operator reported the columns unreadable when judging acceptance criterion 2.
Each rendered reader carries its own Copy control — the Operator will paste one reader's version into one message. Copy takes that reader's prose as plain text, without the surrounding page furniture.
The pitch carries its own Copy control, the same as a reader's — plain text, its prose, no page furniture — and is included in the Download. The overview travels with the run.
The leave-behind carries its own Copy control, the same as the pitch's and a reader's — plain text, its rendered case, no page furniture — and is included in the Download. Where its second call did not run (§3.3c, all three new inputs empty), the copied text simply has no sections 3, 5, or 6 — the same absence as on the page.
The Foundation Document draft carries its own Copy control, the same as the leave-behind's, the pitch's, and a reader's — plain text, its prose, no page furniture — and is included in the Download. The starting point for the work travels with the run.
The run as a whole carries a Download control taking everything as one file: the four fields, the three leave-behind inputs, the pitch, every rendered reader, the leave-behind, the Foundation Document draft, the computed contrast panel, and the check panel. HTML, so it prints from the browser without a separate Print control.
The check panel travels with the output. A downloaded run carrying the prose without the list of inferred specifics hands the Operator the fabrication risk and withholds the thing that flags it. The check panel's copy — including its statement that it does not cover specifics introduced during rendering — appears in the download verbatim.
Copy on a single reader is the exception: it is a deliberate act on one version, and the Operator has the panel on screen when they do it.
Nothing about this persists. Copy is a clipboard action; Download is a client-side blob. No storage, no server round-trip. Same posture as the rest of the page.
Any validation failure at any stage surfaces one plain recovery message and renders nothing malformed. Name what happened, offer the way out, do not apologise, do not expose the stage that failed. Pattern per D8's recovery surface.
A shape or render failure for one reader must not discard the others. Render the columns that succeeded; name the one that did not.
The draft's two calls fail together. The commitments and open-questions calls run under Promise.all, so a failure in either discards the other's output. Observed 2026-07-17: a commitments failure produced a total draft failure, indistinguishable from either call failing, despite the open-questions call having succeeded.
Whether a half-draft should render is a genuine design question — commitments without open questions reads as more settled than it is, which is the opposite of what the split was built for. Recorded as known, not resolved.
The in-block failure message names its own surface. Each failed block says what failed in its own terms — the pitch, a named reader, or the Foundation Document draft — rather than calling every surface a reader. Corrected 2026-07-17 after the generic copy was observed on the pitch and draft blocks.
render can still fabricate. The constraint is in the prompt. Code enforces selection integrity, not prose fidelity. Detecting a fact in the prose that isn't in the findings is a harder problem and is out of scope.Observed 2026-07-17: during wiring, a synthetic run produced a commitment reading "the record of what was approved travels with the work" from input findings that never said it — a provenance-flavoured claim of exactly the kind the split was built to keep out, arriving from the other direction. The subsequent real run on the biotech supplier-agreements scenario produced five commitments, all tracing to input findings, and showed none of this.
This is the standing section 7 limit, now observed on the draft specifically. It matters more here than elsewhere: a fabricated commitment is presented to the prospect as something they said about their own business.
source field, and three guarantees now rest on it. Analyze decides whether a finding traces to the Operator's input or to its own inference. That judgement is prompt-enforced and may be wrong.
When this CR was written, source fed only the check panel. It now also carries the pitch's present-state constraint and the draft's two-call split. The split is structural given correct tags — but if analyze tags an inference as "input", that finding enters the commitments call's context and no mechanism downstream can see the error. The boundary was drawn wrong before the call ran.
Every structural guarantee in this design ultimately routes through a model deciding what to hand over. That is the design's load-bearing weakness. It is not addressed here.
_lib.js behaviour, which fails open when RATE_LIMIT_KV is unbound. The binding lives only in the Cloudflare dashboard, not in the repo.One of them — "there is no automatic way to surface those linkages" — reads in a room as a diagnosis of the prospect's situation despite its generic framing. A listener does not hear "a playbook of this kind" and exempt themselves.
This is not being tightened. The hedged form is honest about how the model knows the claim, and a stricter rule would push the pitch toward saying nothing about the work's nature, leaving no opportunity to name. The check panel lists these claims, which is the intended containment. It is recorded here so the boundary is known rather than assumed.
Settled by Operator direction, 2026-07-16: the spike sits behind Cloudflare Access from the first deploy. It is reachable from the web, not local-only.
The spike is not public. It is not linked from navigation, the home page, or any sitemap, and carries a noindex robots meta tag — same posture as the Harvest Surge mockups.
The Access application covers both the page and its API routes. /sales-generator/ and /api/sales/ are gated together. Gating the page alone leaves the generation endpoints openly callable, which spends the Anthropic budget without the gate. The page's calls are same-origin and carry the Access session.
The Access application must not extend beyond those two paths. The public Example Generator at /example-generator/, its API routes at /api/analyze, /api/illustrate, /api/foundation-draft, the Harvest Surge mockups at /harvest-surge/, and the marketing site itself all stay open. CC verifies this explicitly before the spike is announced as reachable, and reports what it confirmed.
Known limitation, recorded not solved: the Access application and its policy live on the Cloudflare dashboard, outside version control — the same pattern as the RATE_LIMIT_KV binding. Neither is visible in the repository, and neither survives a repository restore.
Policy membership is an Operator decision and is not specified here. CC does not create or modify the Access policy. The Operator configures it.
Rate limiting: a spike-local limiter, settled by Operator direction 2026-07-17.
The shared limiter keys on IP and hour, and on day, with no route in either key, so every function calling it increments the same two counters. Its caps were sized at f2dc67f for a two-call generator. A sales run makes eight requests. Under the shared caps that is two runs per hour before a mid-run lockout, and roughly twelve per day taken from the same pool as the public marketing page.
The spike does not modify the shared limiter — section 2 forbids it, and the public generator depends on its behaviour. Instead functions/api/sales/_lib.js carries its own limiter, keyed rl:sales:ip:${ip}:${hourBucket} and rl:sales:global:${dayBucket}, using the same RATE_LIMIT_KV binding. The two pools do not compete.
Sales caps: 120 per hour per IP, 400 per day global. At eight requests per run that is fifteen runs per hour and fifty per day. Sized for Operator use behind Access, not for public traffic.
The public generator's 20 per hour and 100 per day are unchanged.
Fail-open is retained, matching the shared limiter: an unbound RATE_LIMIT_KV disables limiting with a console warning. Behind Access the exposure is bounded to whoever the Operator admits to the policy. Noted, not solved.
analyze.js with its schema and validation. Verify locally: real input returns valid structured findings with sane source classification.shape.js with partition validation. Verify: two readers over one analysis produce genuinely different selections.render.js. Verify: prose per reader from selection only.Halt after step 2 and report. If two readers over one analysis produce near-identical selections, the thesis has failed and steps 3–6 are wasted. That is the cheapest available kill point, and it comes before any prose is written.
The spike is accepted when the Operator can, locally:
Acceptance is not correctness. It means the surface works well enough to answer the thesis question. The Operator answers that by reading the output, not by the tests passing.
RATE_LIMIT_KV bound locally or failed open._lib.js, analyze.js, illustrate.js, foundation-draft.js, and example-generator.astro are unmodified.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Example Generator — Sales Perspective Spike — CR-2026-152 — v0.21 — 2026-07-17