Version. 0.4 Date. 2026-04-28 Status. Fourth capture. Four threads: (1) Shape as complete specification, specialist as any production system. (2) Executor opacity and AI-capability headroom. (3) The Loompa grammar — thirteen universal specification elements. (4) Memory expectations and gap detection — the system prompts the Operator for missing knowledge before production. Structure and intent clear on all four. Provenance. Extended session 2026-04-28. Threads 1–3 from earlier in the session. Thread 4 emerged from the geology seed exercise: R-A11's declared shape types projected knowledge the Operator doesn't have at seed time. The Operator noted that the system needs a way to remind or solicit data needed for shaping and rendering when it won't be found naturally in the field. This surfaced a gap in the pipeline architecture — no mechanism for detecting absent knowledge before production.
(Unchanged from v0.2. Full text in prior version.)
Summary. A Shape is a complete specification — not intent, not a brief, not partial guidance. The specialist translates faithfully from specification to medium. The pipeline (Memory → Manifestation → Shaping → Rendering) is unchanged. What changes is the richness of what flows through it and the diversity of what connects at the specialist boundary. Render surfaces include documents, applications, architectural drawings, 3D printer specs, musical scores, video, and anything a production system can produce from a specification.
(Unchanged from v0.2. Full text in prior version.)
Summary. The pipeline defines contracts. Executors fulfill them. AI capability improvements flow through executors without changing the pipeline. The current SkillExecutor / AgentExecutor distinction is a barrier to collapse into a unified executor interface. The architecture must not diminish or put barriers in the way of AI enhancements across all four areas: Memory (contribution extraction), Manifestation (organization), Shaping (specification production), and Rendering (artifact production).
The Operator directed: "We need to look at every Render surface we can think of and work backwards." The grammar was not designed from principles. It was extracted empirically by:
Total: 78 distinct artifact types tested. Zero failures.
Every specification, regardless of domain or artifact type, carries all thirteen. They are not imposed — they are the minimum structure any complete specification requires for a specialist to produce faithfully.
Every artifact uses at least one dimension. Many use two or three. An interactive application uses all three.
Seventy-eight artifacts distribute across six primary types with two having subtypes. The types describe what the artifact structurally IS, not what domain it comes from.
Spatial (20 artifacts). Elements positioned in space.
Procedural (16 artifacts). Ordered steps to produce or accomplish something. Cocktail recipes, surgical procedures, knitting patterns, lab protocols, assembly instructions.
Presentational (12 artifacts). Knowledge organized for comprehension.
Temporal (10 artifacts). Content structured over duration. Film screenplays, musical scores, fireworks shows, choreography, podcasts.
Interactive (9 artifacts). States, transitions, and user engagement with response. Web applications, escape rooms, crossword puzzles, board games, dashboards.
Volumetric (7 artifacts). Three-dimensional geometry with material and fabrication properties. 3D print specs, prosthetic fittings, manufacturing specs, protein models.
Proportional (4 artifacts). Ratios and relative quantities as the core structure. Perfume formulations, wine blends, typeface metrics, financial models. Small as a primary type because proportion usually appears as a secondary dimension in other types.
Thirty of 78 artifacts (38%) carry a secondary type. This is the norm, not the exception:
The grammar handles hybrids because all thirteen elements apply regardless of type combination. The type classification determines which arrangement dimensions are primary; the grammar elements are the same.
Tabular data was a format, not a structural type. A bill of materials serves a fabrication need. A timetable serves a temporal need. A spreadsheet is a tool, not a structural category.
Communication sequence was temporal + presentational. A course curriculum is procedural. An email campaign is temporal. Each redistributed to its actual structural type.
Data visualization merged into interactive (dashboards with user engagement) or presentational (static infographics) depending on whether the artifact responds to the consumer.
The Operator noted that the Forge specification format (REQ-NNN tables) already embodies this grammar for software requirements: atomic elements, uniform structure per element, banned ambiguity, explicit dependencies, binary acceptance criteria, completeness validation via induction criteria. The Loompa grammar generalizes what Forge does for software requirements to specifications in any domain. The structural principles are identical — atomicity, uniform structure, precision enforcement, dependency tracking, completeness checking. The content changes by domain. The grammar does not.
A skill implements the grammar. The thirteen elements are a known, fixed structure. The Shaping rules tell the skill what to select and how to organize. The source material (Manifestation) is already organized. The skill's job is: read the organized material, read the rules, populate the thirteen elements, validate completeness, output the structured specification. This is a bounded transformation — input in, output out. No reasoning, no iteration, no judgment calls required.
The Operator does not need to understand the grammar. The Operator writes Shaping rules in domain language: "Select the structural calculations, room dimensions, and code requirements for the floor plan." The skill translates those rules into the thirteen-element structure. The Operator sees the output and confirms it as a complete specification. The grammar is invisible machinery.
Judgment lives in two places the skill does not touch: the Operator writes the rules (domain expertise), and the Operator confirms the Shape (professional judgment). The skill is the mechanical step between.
The geology seed exercise exposed the gap. The first draft (v0.1) of the geology engagement seed included detailed render types — stereonets, alteration zone maps, interpretive cross-sections — that the Operator could not know at seed time. Those renders depend on observations that haven't happened yet. The Operator doesn't know they need cross-sections until they've mapped a structure that warrants one.
The spec anticipated this: R-C5 says a seed that names consumers without declaring projection shapes is complete. But trimming the seed doesn't solve the deeper problem: when the Operator returns from the field and triggers Shape production, how does the system know whether Memory contains enough for a complete specification?
The Operator's framing: "We are going to need a way that an Operator is reminded or solicited for data needed in the shaping and rendering, if it is not going to be found in the field."
The pipeline assumes Memory is rich enough. When the Shaping agent runs, it selects from what exists. If an assertion is missing — no alteration observations contributed, no analogue comparison conducted, no cost estimate entered — the Shape is either incomplete or silently wrong. The Operator may not notice what's absent because absence is invisible.
There is no mechanism at any pipeline stage for saying "you're missing something."
Each DeclaredShapeType and DeclaredRenderType should carry not just rules for production, but expectations about what Memory must contain for production to succeed. The gap between what's expected and what's present is surfaced to the Operator as a prompt.
Three levels:
Shape-type expectations. The DeclaredShapeType carries a checklist: what categories of knowledge Memory must contain before this Shape can be complete. The board briefing shape type expects: opportunity assessment, cost estimate, risk assessment, analogue comparison. If Memory lacks analogue comparison assertions, the system surfaces the gap before the Operator triggers Shape production.
Field-level prompting. If the seed declares that the technical geology Shape needs structural measurements, alteration observations, and geochemistry — and by Day 5 the geologist has structural data and geochemistry but no alteration observations — the system can prompt in real time: "No alteration observations contributed yet. Is this expected for this tenement, or has it not been recorded?"
Pre-Render checking. Before a Render is requested, the system checks whether the confirmed Shape carries everything the DeclaredRenderType needs. A geological map render needs spatial coordinates for every observation. If three voice notes lack GPS tags, the system flags them before the specialist tries to plot empty locations.
The thirteen specification elements work backward as a completeness checklist, not just forward as a specification builder:
The grammar becomes dual-purpose: it structures specifications going forward, and it detects gaps going backward.
R-A11's declared shape types could carry a "Memory expectations" field alongside the selection criteria. The seed says not just "what I'll produce" but "what I'll need to produce it." At the simplest level, this is a list of knowledge categories per shape type. At a richer level, it's a structured checklist with priority (must-have vs. nice-to-have) and timing (needed before field work vs. needed before reporting).
The seed doesn't enumerate specific observations — it names the categories. "Structural measurements" is a seed-level expectation. "Strike and dip on the BIF contact at grid reference 456789" is a field-level observation that satisfies the expectation.
How active should the gap detection be? Three postures:
Passive. The system checks at Shape production time and reports gaps. The Operator sees the gaps and decides whether to address them or proceed with an incomplete specification. This is the simplest implementation and preserves Operator authority — the system reports, the Operator decides.
Prompted. The system monitors Memory as contributions arrive and periodically prompts the Operator: "Board briefing shape type expects an analogue comparison. No analogue comparison assertions found. Would you like to contribute one?" This is more helpful but risks becoming noisy. The prompting must be infrequent, relevant, and suppressible.
Gated. The system prevents Shape production when expectations are unmet. The Operator cannot produce a Shape until Memory satisfies the checklist. This is the most rigorous but violates the Operator-authority principle — the Operator should be able to produce an incomplete Shape if they judge it appropriate (perhaps the analogue comparison is irrelevant for this tenement).
The Operator's directive — "reminded or solicited" — points to the prompted posture, not the gated posture. The system helps; the Operator decides.
DUNIN7 — Done In Seven LLC — Miami, Florida Discovery record — Shape as specification, executor opacity, Loompa grammar, Memory expectations — v0.4 — 2026-04-28