# Scatter Model

> **About the sources:** copies of the outside documents this report draws on have been kept under `canon/` since 2026-07-05. Its citations show what it read when it was written and haven't been updated, so to follow one, open the copy under `canon/`.

:::animation HERO
**HERO: one typed model projects everywhere**
- **What it shows:** a single typed object glows at the center on a steely-gray metal-planet canvas, then fans out projection beams to five destinations at once, a DATABASE SCHEMA, BACKEND TYPES, FRONTEND TYPESCRIPT AND ZOD, FORMS, and TEMPLATES; edit the central model and all five destinations reshape in lockstep, so the same fact never has to be defined or reconciled twice
- **Narrative role:** sets the thesis and serves as the share/card thumbnail; the whole deck is the argument that one typed intermediate representation projects into the entire stack
- **What it teaches:** Scatter Model turns one typed model into the single source of truth that projects into every layer, killing the model-it-five-times tax
- **Intended impact:** the reader stops picturing a schema tool and starts picturing a single source of truth that radiates into the whole stack
:::

| Field | Value |
|---|---|
| Project | Scatter Model |
| Looikos cluster | Infrastructure & Agent Platforms (the data-modeling primitive) |
| One-line | Pydantic-as-intermediate-representation turned into a product: ECS data architecture made playable, where you world-model a domain from typed objects and talk to built-in agents that update the model, plus ownership of the entire Jinja / dynamic-generation layer. |
| Status | Concept (no live repo found; the discipline is in use across the ecosystem, the productized brand is not yet built) |
| Existing code | None standalone. The Pydantic-IR / ECS discipline lives in the `data-architecture` skill and is applied in WikiDesignCo and elsewhere; Scatter Model is the brand that turns the discipline into a product. |
| Desk | desk-infra (Category 1) |
| Coverage | INFERRED-heavy on the brand (concept stage); VERIFIED on the seed and the cross-ecosystem discipline; market from Perplexity (cited) |
| Date | 2026-06-20 |

---

## Nine-rung frame (this research task)

The research lane behind this deck, held to the symphony-recon Purpose rails: scale Andy Houston to a portfolio of dozens of independently valuable, agent-native brands operated by one person.

- **Purpose (rails):** give the team the depth to build and run Scatter Model with agents, and to seed the world-model the rest of the ecosystem reads.
- **Mission (1):** convert the Scatter Model seed into a research-grounded deck so its build and go-to-market are designed from understanding.
- **Objective (2):** a finished ~10,000-word deck at `symphony/stack-recon/projects/scatter-model.md`, evidence-tagged, graded CLEAN.
- **Initiative (3):** the symphony-recon Track-P run; Scatter Model is brand two of desk-infra's Category 1 list, a sibling primitive to WikiDesignCo.
- **Project (4):** the desk-infra deck set; done when every Category 1 brand is graded.
- **Task (5):** this deck, against `_PROJECT_TEMPLATE.md` and PST.
- **Action (6):** A1 ingest the seed (no live repo found). A2 skeleton. A3 sequential Perplexity. A4 PST. A5 incremental fill. A6 self-check. A7 hand to the lead.
- **Decision (7):** evolution stage per capability (heuristic: Wardley from reception; authority: within-desk, and flagged higher-INFERRED because the brand is concept-stage with no live code to read); persona set (5+ at depth; within-desk); the Now/Next/Watch/Leave instinct (heuristic: VALUE_RUBRIC.md; authority: desk proposes, lead decides).
- **Data (8):** N/A as a runtime record. This doc is the artifact; components are the template sections, the evidence tags, the word count, the sources.
- **Event (9):** N/A as a captured runtime occurrence. Deck-written-to-disk and the lead's grade are the only events.

## 1. What it is (the one-paragraph truth)

Scatter Model takes the Looikos discipline of treating Pydantic models as the intermediate representation (IR) and turns it into a product. It's the data-modeling primitive for the whole ecosystem. In plain terms, you define a domain once as typed objects, and that one typed model becomes the single source of truth that projects into a database schema, backend types, frontend TypeScript and Zod types, forms, and configs. You shape and explore the model visually, the way you'd world-model when building a role-playing game, while conversational agents update it for you: you keep what you like, and you talk them into adjusting what you don't.

:::animation 1b
**ANIMATION 1b: model the domain like an RPG world**
- **What it shows:** a business domain, a customer, an invoice, a content asset, renders as a playable strategy-game world of units and systems on a steely-gray metal-planet canvas; a builder tunes entities and relationships the way a game designer tunes units, and a conversational agent stands beside them adjusting the model on request, the builder keeping what they like and talking the rest into shape
- **Narrative role:** anchors the §1 playable and agent-native claim, world-modeling like a role-playing game
- **What it teaches:** the model is shaped visually and tuned like a game world while agents update it on request
- **Intended impact:** the reader sees modeling reframed from a settings form into a playable world with an agent partner
::: Scatter Model also owns the entire dynamic-generation layer: the prompt optimization, the programmatic email and content generation, every form, every prompt, and every config file in the ecosystem. The problem it solves is the most unglamorous and most expensive one in software. Data modeling is the foundation every solution stands on, and getting it wrong early means every downstream layer inherits the error and migrations become a permanent tax, yet almost nobody makes modeling fast, visual, agent-native, or unified across the stack. Developers today model the same data three or four times, once in the database, once in the backend types, once in the frontend types, once in the validation layer, and those copies drift apart the moment anyone edits one and not the others.

:::animation 1a
**ANIMATION 1a: the same model, drawn four times, drifting**
- **What it shows:** the same User shape is drawn four separate times, in the DATABASE, the BACKEND TYPES, the FRONTEND TYPES, the VALIDATION LAYER, four copies sitting in parallel; a hand edits one field in one copy and the other three do not move, and hairline cracks of drift open between them until the running app throws a type error at the seam
- **Narrative role:** anchors the §1 problem, modeling the same data three or four times
- **What it teaches:** the copies drift the moment anyone edits one and not the others, which is the everyday tax the brand removes
- **Intended impact:** the reader feels the drift as a concrete, familiar defect rather than an abstract inefficiency
::: The market has proven this pain is real by adopting partial fixes (Prisma unifies the database and the TypeScript client, tRPC and Zod unify backend and frontend types, Pydantic unifies validation and types in Python), but no mainstream tool unifies all of it from one intermediate representation, and none of them makes the model playable or lets agents maintain it (VERIFIED gap, Perplexity Query 1).

:::animation 1c
**ANIMATION 1c: four partial fixes, one unbuilt whole**
- **What it shows:** four tools each bridge one seam and glow, PRISMA joining database and client, TRPC AND ZOD joining backend and frontend, PYDANTIC joining validation and types, each a short bridge over one gap; the seams they leave open still crack, and a single unbuilt span labeled ONE IR UNIFIES ALL OF IT, PLAYABLE, AGENT-MAINTAINED hangs empty above them
- **Narrative role:** anchors the §1 market-proof claim, the partial fixes and the unbuilt unified fix
- **What it teaches:** the market proved the pain by adopting four partial fixes, and no tool unifies all of it from one IR or makes it playable and agent-maintained
- **Intended impact:** the reader sees the exact empty position the brand is built into, validated by the partial fixes around it
::: Scatter Model is built for the builder, the operator, and the domain expert who need a clean typed world-model behind every solution and don't want to hand-write or hand-reconcile it five times. It's concept-stage today, with no standalone repo, though the discipline it productizes already runs across the ecosystem through an internal derivation engine for data architecture, so the brand is the product wrapper around a proven internal practice rather than an untested idea (INFERRED brand status; VERIFIED that the discipline is in use).

## 2. Andy's seed, expanded

**Andy's words (verbatim from the ecosystem capture):** "Scatter Model (Pydantic-IR becomes a platform). Where the Pydantic-as-intermediate-representation discipline turns into a product. It is ECS data architecture made playable: you world-model the way you would when building an RPG, except you start from Pydantic objects and play with every detail of the model. Built-in agents you talk to go and update everything; if you like it you keep it, if not you talk to them and they adjust. The aesthetic Andy wants is a 1990s Total Annihilation feel, the steely-gray metal-planet vibe. The data-modeling primitive of the ecosystem. Scatter Model also owns the entire Jinja / dynamic layer: all dynamic prompt optimization, programmatic email and content generation, every form, prompt, and config file. Pydantic-as-IR splits out to Zod/TypeScript, which handles ~95% of use cases. ECS data modeling exists to build solutions; that is where data modeling and the rest connect." The name's origin, recorded elsewhere in the ecosystem notes, is its own thesis statement: what happens when you apply too much weaponized autism to Pydantic.

**Reading between the lines.** Four things sit compressed in that seed, and the market research behind this deck confirms that each one is a real position and largely unoccupied.

The first is that "ECS data architecture made playable" is a real product decision, not a metaphor. Entity-component-system modeling is how game engines represent worlds: entities are bare identifiers, components are pure data attached to them, and systems are the logic that runs over components. Andy's move is to treat business-domain modeling the same way, so a customer, an invoice, a content asset, or a persona is an entity with components, and the modeler builds and tunes that world the way a strategy-game designer tunes units. The look Andy wants, the steely-gray metal planets of the 1990s strategy game Total Annihilation, is the deliberate skin on that: data modeling presented as a strategy game you play on a metal planet rather than a form you fill in a settings panel. That's a real differentiator, because the visual tools that exist (ERD diagrammers) aren't the operational source of truth and don't round-trip, while the playable low-code tools (Airtable, Retool) have soft proprietary schemas with no typed IR underneath (VERIFIED gap, Perplexity Query 1). Scatter Model's playability is meant to sit over a hard typed IR, which is the combination nobody ships.

:::animation 2a
**ANIMATION 2a: entities, components, systems on a metal planet**
- **What it shows:** a customer, an invoice, a persona render as bare entity identifiers, pure-data components clip onto each one, and systems run over the components, the whole thing tuned on a 1990s steely-gray metal-planet canvas like a strategy-game designer tuning units; below it a hard typed IR anchors the play, so the playful surface sits on solid structure rather than a soft schema
- **Narrative role:** anchors the §2 reading of ECS-made-playable, the genuine product decision
- **What it teaches:** business-domain modeling is treated like a game engine's entity-component-system, playable on top of a hard typed IR
- **Intended impact:** the reader sees the aesthetic as a real differentiator, playability over a hard IR that nobody ships
:::

The second is the talk-to-agents-and-they-adjust loop, which is the agent-native part. Instead of editing the model by hand, you describe what you want and built-in agents update the entities, components, and relationships, and you accept or refine. The research shows where this has to be careful: most teams accept AI as a copilot but are wary of agents that auto-mutate their schema, so the durable shape is a proposal-and-review workflow where agents propose model edits, show the blast radius (the migrations, the API changes, the UI changes a given edit would cause), and humans accept with a diff (VERIFIED design caution, Perplexity Query 1). Andy's keep-it-or-talk-to-them loop is that same proposal-and-review pattern in his words, and it's the validated way to make agent-native modeling trustworthy instead of reckless.

:::animation 2b
**ANIMATION 2b: propose, show the blast radius, accept the diff**
- **What it shows:** a builder describes a change in plain words and an agent proposes a model edit; before anything mutates, the system lights up the blast radius, the MIGRATIONS, the API CHANGES, the UI CHANGES that edit would cause, and the human accepts or refines with a visible diff, the agent never silently rewriting the schema
- **Narrative role:** anchors the §2 reading of the talk-to-agents loop, the propose-and-review pattern
- **What it teaches:** agents propose edits and show the blast radius, and humans accept with a diff, which is what makes agent-native modeling trustworthy
- **Intended impact:** the reader sees the agent loop as reviewed and safe rather than a reckless auto-mutation of the schema
:::

The third is why owning the Jinja templating and dynamic-generation layer makes Scatter Model the connective tissue of the ecosystem instead of one more schema tool. Every form, every prompt, every config file, and every programmatic email in every Looikos brand is a template with variables, and if those templates are schema-driven (their variables validated against the same typed IR) then a prompt can never reference a field that doesn't exist, a generated email can never drift from the model, and a form regenerates when the model changes. The research names this as a real, unsolved edge: the dynamic-template layer is almost always a separate tool that lives beside the data models rather than being a typed consequence of them (VERIFIED gap, Perplexity Query 1). Tying the two together is the move that turns Scatter Model from a modeling studio into the layer that guarantees correctness across both the structure and the behavior of every solution the ecosystem ships.

:::animation 2c
**ANIMATION 2c: templates as typed consequences of the model**
- **What it shows:** a prompt, a generated email, a form, and a config file each try to reference a field; a line runs from every template variable back to the typed IR and validates against it, so a template that names a field the model does not have flashes red and is rejected, and when the model changes the forms and prompts regenerate to match
- **Narrative role:** anchors the §2 reading of owning the Jinja and dynamic-generation layer
- **What it teaches:** tying every template's variables to the typed IR guarantees correctness across both structure and behavior
- **Intended impact:** the reader sees why owning the template layer makes the brand the connective tissue rather than just a schema tool
:::

The fourth is the Pydantic-IR-to-Zod-and-TypeScript split, which is the pragmatic reach. Pydantic is Python-only, so the IR has to project into the TypeScript world (Zod for runtime validation, plain TS types for the compiler) to cover the frontend, and Andy's note that this split handles roughly ninety-five percent of use cases is the realistic scoping. The research adds a caveat: one IR for every backend risks becoming either a lowest-common-denominator model that loses expressiveness or a complex DSL nobody enjoys, so the sound architecture is a core IR (entities, fields, relationships, constraints) plus per-backend projection layers with manual overrides where a target's constraints demand them (VERIFIED caution, Perplexity Query 1). Scatter Model is the consumer-facing sibling of the discipline WikiDesignCo's platform runs on internally, and a peer of Story Factory, the brand that owns the structured-document side of the same generation problem. ECS data modeling exists to build solutions, and Scatter Model is where the data model and everything built on it connect.

:::animation 2d
**ANIMATION 2d: the Python IR reaches into TypeScript**
- **What it shows:** a Pydantic IR sits in the Python world and a beam projects across a boundary into the TypeScript world, splitting into ZOD for runtime validation and plain TS TYPES for the compiler; a meter reads ~95% OF USE CASES COVERED, while a small honest note shows a core IR plus per-backend projection layers with manual overrides where a target's constraints demand them
- **Narrative role:** anchors the §2 reading of the Pydantic-IR-to-Zod-and-TypeScript split, the pragmatic reach
- **What it teaches:** the IR projects from Python into the TypeScript frontend and covers most cases through a core plus per-backend projections
- **Intended impact:** the reader sees the split as realistic scoping rather than a claim of one model for literally everything
:::

## 3. The three-angle valuation (the core of a self-standing brand)
<!-- STUB ~2,400w total. Institutional/M&A read, real numbers. -->

### 3a. Finance (credit and capital access)

The finance read on a developer-and-data-platform brand turns on one structural fact: a tool that becomes the source of truth for a domain's data model is one of the stickiest things in software, because ripping it out means re-modeling everything it touches. That stickiness is the foundation of the credit and valuation story, and it's why the category's comparable companies (comps) are valued so high.

The economic activity is recurring revenue with two natural meters: a seat or subscription meter for the human modelers who use the visual studio, and a usage meter for agent access (agents reading and proposing model edits through MCP, the Model Context Protocol agents use to reach tools; codegen runs; dynamic-template renders). Because Scatter Model is concept-stage with no live revenue, the throughput numbers here are INFERRED projections rather than VERIFIED receipts, and the deck says so plainly. What can be anchored is the quality profile the category exhibits: developer tools that embed in the data layer show high net revenue retention because adoption spreads from one team to the whole engineering org and because the switching cost rises with every artifact the IR generates. The credit story rests on the quality of that annual recurring revenue (ARR). Recurring revenue with high retention and expanding seats is the cleanest collateral a software business can offer a revenue-based-financing desk or a venture-debt lender, and the embedded-in-the-data-layer stickiness makes the forward revenue unusually forecastable.

:::animation 3a1
**ANIMATION 3a1: the source of truth is the stickiest thing to rip out**
- **What it shows:** the IR sits at the center of a stack as the source of truth, with every schema, type, form, and template generated from it and hanging off it; a hand tries to rip the IR out and the whole generated stack would have to be re-modeled, so the pull-out stalls, and a retention meter climbs as adoption spreads from one team across the whole engineering org
- **Narrative role:** anchors the §3a finance read, the stickiness that founds the credit and valuation story
- **What it teaches:** a tool that becomes the source of truth for a domain's data model is one of the stickiest things in software
- **Intended impact:** the reader sees why the embedded IR is the collateral and the forecastable revenue base
::: The capital path is the standard developer-tooling one: private venture and venture-debt early, with the open-core or open-source-plus-paid-cloud model that the comparable companies use to build a community-led funnel before monetizing the hosted and enterprise tiers (INFERRED from category norm).

The M&A and valuation comps for this category are strong, named, and post-2020 (VERIFIED as market-reported, Perplexity Query 1; the precise valuations are widely reported rather than always company-confirmed, tagged accordingly). On the low-code and internal-tools side, Airtable raised a $735M Series F in 2021 at a reported $11B valuation, and Retool raised at a reported ~$5B in 2021 with secondary deals reportedly pushing toward $6B-to-$8B after. On the data-API and schema side, Hasura raised a $100M Series C in 2021 at a reported ~$1B, Supabase raised over $100M across 2021-to-2022 rounds at hundreds-of-millions valuations, and Prisma raised a Series B in 2021 at a commonly cited $400M-to-$600M range (not company-confirmed, tagged INFERRED-on-the-exact-figure). For broader dev-tool context, Vercel, Postman, and Snyk each raised at multi-billion valuations in the same window, which establishes that capital markets pay up for tools that become the central nervous system of a development workflow. The strategic-acquisition pattern reinforces it: the large platforms buy the semantic and modeling layer specifically (Google bought Looker, Salesforce bought Tableau, ThoughtSpot bought Mode), because owning the definition layer is strategically valuable to a bigger stack (VERIFIED pattern, Perplexity Query 1).

:::animation 3a2
**ANIMATION 3a2: the big platforms buy the definition layer**
- **What it shows:** a row of category comps rises, AIRTABLE at a reported eleven billion, RETOOL toward six to eight, HASURA around one, PRISMA in a several-hundred-million range; then three acquisition arrows fire as big platforms reach specifically for the modeling layer, GOOGLE taking Looker, SALESFORCE taking Tableau, THOUGHTSPOT taking Mode, each labeled OWN THE DEFINITION LAYER
- **Narrative role:** anchors the §3a M&A comps read and the strategic-acquisition pattern
- **What it teaches:** the category comps run from hundreds of millions to eleven billion, and big platforms buy the definition layer specifically
- **Intended impact:** the reader sees the software-angle ceiling and why owning the modeling layer is a strategic acquisition target
:::

Set the $10M floor that applies to every Looikos brand against those comps and the conclusion is the same as for the others: the service angle alone reaches $10M, and a tool in a category whose comparables run from hundreds of millions to eleven billion has a software-angle ceiling far above that. The caveat is a concept-stage discount. Scatter Model has no ARR yet, so it's valued today on the strength of the thesis, the proven internal discipline, and the category comps, not on a revenue multiple, and the deck holds that distinction rather than projecting a fictional ARR (INFERRED valuation framing; the $10M-floor logic is VERIFIED from LOOIKOS §1.5, its application to an unbuilt brand is tagged OPEN until real traction exists).

A market maker's three-level read (fundamentals, technicals, sentiment) closes the finance angle. The fundamentals are the category's retention-and-expansion economics, strong once embedded but unproven for this specific brand. The technicals are the open-core community funnel the comparable companies all use, the channel mechanics Scatter Model would adopt. The live sentiment is a real tailwind: the market is actively rebuilding its semantic and modeling layers to be agent-native (dbt's semantic layer, Holistics, Rill, Pydantic repositioning as an AI-engineering stack), which is the wave Scatter Model rides rather than fights (VERIFIED trend, Perplexity Query 1). Sentiment is moving toward what the brand is, and that's the most favorable reading a young brand in this category can get.

### 3b. Software (the interface stack)

Software is the load-bearing angle for Scatter Model, because the brand is a developer-and-data platform first and a service second. The product is one typed intermediate representation exposed through many surfaces, and the discipline that keeps it coherent is the same hexagonal pattern the whole ecosystem runs on, with one core and many surfaces: the IR and its operations live in a core, and every interface is a thin adapter over it.

The surfaces map to revenue lines deliberately. The visual modeling studio, the playable Total-Annihilation-aesthetic canvas where a human shapes the ECS world, is the SaaS subscription surface for human operators. The MCP server is the agent-native surface where agents read the model and propose edits, and that agentic access is the credit-metered pattern that monetizes the way the rest of the ecosystem monetizes agentic consumption. The CLI and the API support a credit-and-subscription program for programmatic consumers and for CI pipelines that run codegen on every commit. The codegen and export engine (Pydantic-IR projecting into database schemas, FastAPI models, Zod, and TypeScript types) is the feature that creates the switching cost, because once a team's whole stack is generated from the IR, the IR is the source of truth and leaving means re-modeling everything.

:::animation 3b1
**ANIMATION 3b1: the codegen engine that builds the switching cost**
- **What it shows:** the IR core sits at the center and the codegen engine projects it outward into a DATABASE SCHEMA, FASTAPI MODELS, ZOD, and TYPESCRIPT TYPES, each generated artifact snapping into the running stack; as more of the stack is generated from the IR, a switching-cost gauge climbs, because leaving now would mean re-modeling the whole thing by hand
- **Narrative role:** anchors the §3b software surfaces, the codegen engine as the switching-cost feature
- **What it teaches:** once a team's whole stack is generated from the IR, the IR is the source of truth and leaving means re-modeling everything
- **Intended impact:** the reader sees the codegen engine as the mechanism that turns adoption into a durable lock-in
::: The dynamic-generation engine (the Jinja layer: prompt templates, programmatic email and content, forms, configs) is a monetizable surface of its own. Tools like it are sold today as a separate category (the prompt-ops tools, the template managers), so Scatter Model's version, with templates as typed consequences of the model instead of a tool beside it, is a differentiated product, not a feature (VERIFIED gap, Perplexity Query 1).

The platform breaks down into feature factories with clean domain boundaries, each maintained largely by its own agent harness (the tools, prompts, and checks an agent runs inside). Four are legible from the seed and the research. The model-editor factory runs the visual ECS studio and its round-trip to the text IR. The agent-update factory runs the propose-review-accept loop, including the blast-radius preview the research treats as a requirement, so an agent's proposed edit shows the migrations, API changes, and UI changes it would cause before a human accepts. The dynamic-template factory runs the schema-driven Jinja layer with validated variables, and the codegen-and-export factory runs the per-backend projection layers. Each is a set of harnesses plus a gateway harness specialized for its domain, the modular, composable harness pattern that the ecosystem's agent framework, Harness V2, provides `HARNESS_V2_CONSOLIDATED_BRIEF.md`.

The research shapes the software architecture in three ways, and the deck builds all three in. First, the per-backend caveat from the seed applies with more force here: a single model that must satisfy SQL, NoSQL, search indexes, and event streams tends to collapse toward a lowest common denominator, so the core IR gets per-backend projection-and-mapping layers with manual overrides (VERIFIED caution, Perplexity Query 1). Second, visual playability can't fight Git and code: the durable dev tools are text-first and visually explorable, so the playable canvas has to be a front-end over a text IR (the Pydantic models, the YAML) with full round-trip and Git integration, not a proprietary editor that becomes the only canonical home (VERIFIED caution, Perplexity Query 1). Third, owning the dynamic-template layer is powerful but overloaded, so the wedge should start narrow, with one or two high-leverage template surfaces (AI-generated transactional emails tied to models, AI-generated type-correct CRUD dashboards) before expanding into generic template management (VERIFIED scoping, Perplexity Query 1). All three are the engineering shape that makes the thesis shippable.

The differentiation from the nearest convergent competitor is the sharpest software decision. Pydantic AI is repositioning Pydantic as an AI-engineering stack where typed models structure agent inputs and outputs, which overlaps Scatter Model's agent-native-IR space (VERIFIED, Perplexity Query 1). The clean separation is that Pydantic AI builds type-safe agents on top of models you already have, while Scatter Model builds and maintains the models themselves in a visual, agent-native way and propagates them into every backend and template. Scatter Model rides the Pydantic wave: it's built around Pydantic as its IR, so it slots into the Python ecosystem and extends Pydantic AI instead of competing with it, which is both the safer go-to-market and the more defensible position (VERIFIED strategic read, Perplexity Query 1).

:::animation 3b2
**ANIMATION 3b2: build the models, do not just consume them**
- **What it shows:** on one side PYDANTIC AI builds type-safe agents standing on top of models a team already has; on the other side SCATTER MODEL builds and maintains the models themselves in a visual agent-native studio and projects them into every backend and template; a shared Pydantic wave carries both forward, Scatter Model riding it and extending Pydantic AI rather than colliding with it
- **Narrative role:** anchors the §3b differentiation against the nearest convergent competitor
- **What it teaches:** Pydantic AI builds agents on top of existing models, while Scatter Model builds and maintains the models themselves and rides the same wave
- **Intended impact:** the reader sees the clean separation that makes the position defensible rather than a collision
:::

### 3c. Service (premium-at-accessible boutique delivery)

The service angle for Scatter Model is data-architecture-as-a-service: model a client's entire domain for them, deliver it as a working typed source of truth, and retain the relationship as their data model evolves. The delivery engine already exists internally as the eight-step derivation that turns a problem story into a complete ECS data catalog with Pydantic models (problem to story to world-model to solutions to features to systems to components to entities), which is the productized practice the brand wraps (VERIFIED that the derivation discipline exists; its packaging as a Scatter Model retainer is INFERRED).

The target client is the buyer every Looikos brand serves, applied to this domain: a business of fewer than 25 employees run by someone with deep, real, non-replicable domain expertise who can't turn it into a working data structure. The research finds this person in three places. They are the founder whose app rotted because the data model was wrong from the start and whose migrations are now hell, or the domain expert whose mental model is rich but who has no path from that mental model to a typed schema, or the team that models the same data three times and watches the copies drift. They've mastered their domain and not data architecture, and the derivation engine plus the visual studio bridges their expertise into a clean model without them having to become data engineers (VERIFIED persona structure, Perplexity Query 1; the service framing INFERRED).

:::animation 3c1
**ANIMATION 3c1: expertise bridged into a clean model**
- **What it shows:** a domain expert holds a rich tangle of lived process knowledge, full of exceptions and edge cases, that they cannot turn into tables; the eight-step derivation engine, problem to story to world-model to solutions to features to systems to components to entities, runs their knowledge through and a clean typed ECS catalog crystallizes on the other side, without the expert ever having to become a data engineer
- **Narrative role:** anchors the §3c service angle, the derivation engine serving the master-complex operator
- **What it teaches:** the derivation engine plus the visual studio bridges deep domain expertise into a clean typed model
- **Intended impact:** the reader sees the service as running a proven engine on the client's expertise rather than from-scratch consulting
:::

The engagement shape is the ecosystem standard. An audit at the start locks the scope (how many domains, how deep, what the deliverable is: a one-time modeled catalog, an ongoing model-maintenance retainer, or a sprint-based engagement), and the platform quantifies the price against that audit so the client sees a predictable number. Premium quality at accessible pricing is possible here for the same reason it is across the ecosystem: the brand has already built the modeling engine and the agent harnesses, so delivering a client's data architecture is a matter of running a proven system with expert oversight rather than artisanal from-scratch consulting, which is the compression that lets one operator-architect deliver what a senior data-engineering team would (INFERRED from the ecosystem compression pattern, VERIFIED that the engine exists). The accessible-product tier sits around $1-2k/month and retainers around $2-12k+, the standard Looikos economics, and at the standard 100 to 250 retainer customers the service angle floors around $1M/month (VERIFIED framing, LOOIKOS §1.5; the customer count applied to this brand is the standard, not a current-pipeline projection, tagged OPEN).

The commodity work beneath the premium engagements (routine schema cleanups, simple migrations) goes to the ecosystem's sister network of affiliate specialists, so service at scale becomes a network problem instead of a headcount problem, and the relationship runs on the customer-success model the brands share `THE_FLOOR.md`. The relationship is the irreducibly human part, and the modeling engine exists to make one person capable of delivering it at portfolio scale. A client may see data architecture as a one-time deliverable, so the retainer logic depends on positioning the engagement as ongoing model stewardship (the model changes as the business changes, agents propose edits, the stewardship is continuous). The research independently puts the durable value there too, in the governed review-and-certification loop rather than the one-shot model (VERIFIED stewardship framing, Perplexity Query 1).

:::animation 3c2
**ANIMATION 3c2: from one-shot model to ongoing stewardship**
- **What it shows:** a client's data model is delivered once and would normally sit static and end the relationship; instead the business changes and the model changes with it, agents proposing edits, a governed review-and-certification loop turning, so the engagement becomes continuous stewardship where the model is kept alive rather than shipped and abandoned
- **Narrative role:** anchors the §3c service subtlety, positioning the engagement as ongoing model stewardship
- **What it teaches:** the durable value sits in the governed review-and-certification loop, not the one-shot model, which is what makes the retainer real
- **Intended impact:** the reader sees why a one-time-feeling deliverable becomes a lasting stewardship relationship
:::

## 4. The personas (5+, modeled to world-experience depth)

The six personas here speak in the first person, at world-experience depth, and carry the pain in close-to-real developer and operator language. Their language is INFERRED representative voice: the voice-of-customer research returned constructed but realistic phrasings (it flagged them as such), corroborated by real Hacker News and developer-emotion threads, so the phrases are representative, not documented quotes. The bias is toward the negative emotions, because that's where these people live, and the shame layer in developer culture is unusually sharp (the industry runs on public competence signals, so admitting the schema is broken is admitting you are).

:::animation p0
**ANIMATION p0: six people, one broken foundation**
- **What it shows:** six figures stand around a single dark loop labeled the cycle of suffering, each entering at a different surface, modeling the same data four times, a rotted schema, a domain that will not fit tables, prompt and config sprawl, endless codegen glue, a world that will not become playable, yet all circling the same buried belief at the center reading MODELING IS OVERHEAD, I'LL FIX IT LATER; a lit far bank marked ONE PLAYABLE AGENT-TENDED SOURCE OF TRUTH is visible and none has reached it
- **Narrative role:** frames the whole persona section, the shared belief underneath six surfaces
- **What it teaches:** the six personas differ on the surface and run the same loop around one belief, that modeling is a tax to defer rather than the product
- **Intended impact:** the reader reads the personas as one structure with six entry points rather than six unrelated buyers
:::

### P1. The developer modeling the same data four times

Why the hell am I defining the same User shape in the database, the ORM, the backend type, the frontend TypeScript, and then again in the validation schema, and how is this normal? Every time product adds one field I go on a scavenger hunt through four layers of truth that all disagree with each other. Type safety means nothing if Postgres says one thing, the ORM says another, Zod says a third, and the React app dies at runtime anyway. I spend more time reconciling types than building features. I'm basically a type janitor, and production is a bug lottery where the frontend thinks price is a string, the backend thinks it's a float, and the database has it nullable.

When a field mismatch slips through and breaks in prod, people think I'm sloppy, even though the process is broken. I got here because every framework I adopted solved one seam (Prisma the database-to-client seam, tRPC the backend-to-frontend seam, Pydantic the validation-to-types seam) and I assembled them, and the assembly is the problem because no two of them share a source of truth (VERIFIED structure, Perplexity Query 1). Getting out takes one intermediate representation that all the layers project from, which is what Scatter Model is; the brand exists because the market has proven the pain by adopting four partial fixes and still drifting. Most developers stay stuck because the duplication is normalized: everyone does it, so it reads as the cost of doing business instead of a solvable defect. Staying costs me the slow erosion of trust in my system, never fully believing a deploy, and the quiet fear that other devs have beautiful end-to-end types, so maybe I'm just not good enough. Leaving costs adopting a single source of truth and letting it generate what I used to hand-reconcile (voice INFERRED, Perplexity Query 2; gap VERIFIED, Query 1).

:::animation p1
**ANIMATION p1: the type janitor freed**
- **What it shows:** a developer runs frantically between four layers of truth that all disagree, Postgres saying one thing, the ORM another, Zod a third, the React app dying at runtime, a name tag reading TYPE JANITOR; then one intermediate representation drops in that all four layers project from, the disagreements vanish, and the tag falls off as the developer turns to building features
- **Narrative role:** anchors persona 1, the developer modeling the same data four times
- **What it teaches:** one IR that all layers project from ends the reconciliation and lets the developer build instead of janitor types
- **Intended impact:** the reader sees the daily reconciliation grind and the single-source-of-truth relief that ends it
:::

### P2. The founder whose schema rotted

We hacked the schema together to ship v1 and now every feature feels like arguing with a past version of myself. Our database is a monument to all the bad decisions we made in the first three months. Any migration is a heart attack: I run it, stare at the logs, and pray the webhooks don't explode. We have tables named user, users, and user_profile that all kind of mean the same thing but not really, and nobody wants to touch them. Changing one column name is like defusing a bomb with my teeth. I keep thinking if we had just spent an extra week modeling this properly, and it's way too late now.

I approved this schema, so admitting it's broken means admitting I screwed up the foundation, and investors and customers think we're more solid than we are. The move-fast pressure made modeling feel like overhead and shipping feel like the real work, so the model was the corner I cut, and the cut compounded with every feature built on top of it. I need a way to remodel the domain cleanly and migrate toward it with the blast radius visible before each change, and that's the propose-review-with-blast-radius loop Scatter Model is built around (VERIFIED design fit, Perplexity Query 1). Founders like me stay stuck because refactoring the schema risks breaking the business, not refactoring means slow death by complexity, and either path feels like my fault, so the safest-feeling move is to keep wrestling the legacy tables. Meanwhile every new feature is eighty percent fighting legacy and twenty percent real work. Getting out means taking the identity hit of admitting real engineers get the foundation right up front, and choosing to fix it anyway (voice INFERRED, Perplexity Query 2).

:::animation p2
**ANIMATION p2: the migration bomb, defused before it detonates**
- **What it shows:** a founder stands over a rotted schema with tables named user, users, and user_profile, sweating as a migration script hovers like a bomb wired to production; then the propose-review loop shows the blast radius of the change in advance, every affected webhook and API and screen lit up before anything runs, and the founder remodels toward a clean domain with the explosion visible and contained
- **Narrative role:** anchors persona 2, the founder whose schema rotted
- **What it teaches:** the propose-review-with-blast-radius loop removes the migration terror by showing the damage before the change runs
- **Intended impact:** the reader feels the migration dread and sees exactly what makes remodeling survivable
:::

### P3. The domain expert who cannot express their model

I know exactly how our business works, but the moment someone says so what are the tables, my mind blanks. All these tools assume you already think in schemas, and I don't. I think in how the work actually happens. I can explain the rules to a human in five minutes and I can't for the life of me turn that into a database design. Every no-code tool I try immediately asks me to define tables and relationships, and if I could do that I wouldn't need a no-code tool. I keep telling the devs it isn't just customers and orders, there are exceptions and weird cases, and they tell me that doesn't fit the model.

Everyone acts like this is simple modeling, so I quietly wonder what's wrong with me that I can't do it, and I'm scared to push back on the devs because they might decide I'm non-technical and stop listening. My expertise built up as lived process knowledge, rich in exceptions and edge cases, and the tools all demand I first translate it into the abstract table-and-relationship form, which is the one skill I don't have. What would get me out is a modeling surface that starts from the domain concepts and the process instead of from tables, and an agent I can talk to that turns my five-minute human explanation into the typed structure. That's the talk-to-agents-and-they-build-it loop at the center of Scatter Model (VERIFIED fit, the seed; the persona pain VERIFIED-structure from Query 1). Most people in my spot fail because the tools repel anyone who doesn't think in schemas at the first screen, so the domain expert stays dependent on developers for every change and the messy real parts never make it into the model. If I stay stuck, the system encodes a simplified, wrong version of reality, because I couldn't express the exceptions in their language. Getting out asks me to trust a tool that meets me on my terms (voice INFERRED, Perplexity Query 2).

:::animation p3
**ANIMATION p3: the domain expert met in their own terms**
- **What it shows:** a domain expert explains the real work in five plain minutes, rich with exceptions and weird cases, while every no-code tool shoves a blank TABLES AND RELATIONSHIPS screen at them and they freeze; then an agent listens to the plain explanation and turns it into a typed structure that keeps the exceptions, the modeling surface starting from concepts and process rather than from tables
- **Narrative role:** anchors persona 3, the domain expert who cannot express their model
- **What it teaches:** a talk-to-agents loop that starts from the domain and the process turns human explanation into a typed model without table-thinking
- **Intended impact:** the reader sees how the brand reaches the expert the schema-first tools repel at the first screen
:::

### P4. The team lead drowning in prompt and config sprawl

We have prompts copy-pasted in five services, three frontend components, and two cron jobs, and none of them match. Someone tweaks a field name in one place and suddenly half the prompts are silently wrong, no tests fail, the model just starts acting weird. There's no single source of truth for prompts or configs; it's tribal knowledge and grep. I keep finding slightly different versions of the main system prompt and nobody knows which one is real. We treat prompts like strings we copy-paste instead of like code we can reason about, and I'm pretty sure we're one quick fix in production away from never being able to reproduce our own behavior.

I'm supposed to be the one keeping this under control, I've let a mess grow that I can't fully untangle, and if a subtle prompt bug hits production, leadership blames me for not having processes. Prompts and templates started as quick strings and were never promoted to first-class artifacts, so they spread by copy-paste faster than anyone could centralize them, and the config sprawl followed the same path. The way out is a single source of truth where every template's variables are validated against the typed model, so a prompt can't reference a field that doesn't exist and a template regenerates when the model changes. That's the schema-driven Jinja layer Scatter Model owns (VERIFIED fit, the seed; the gap VERIFIED from Query 1, where the dynamic-template layer is named as almost always a separate tool that drifts from the models). Most teams fail here because the sprawl is invisible until it breaks silently, and silent breakage produces no failing test to force the fix. Staying stuck means losing the mental model of my system while I'm still responsible for it, the specific terror of this role. Getting out means treating prompts and configs as typed artifacts instead of strings (voice INFERRED, Perplexity Query 2; gap VERIFIED, Query 1).

:::animation p4
**ANIMATION p4: prompts promoted from strings to typed artifacts**
- **What it shows:** the same system prompt exists in five slightly different copy-pasted versions scattered across services and cron jobs, and a field rename silently breaks half of them with no failing test; then every template's variables bind to the typed model, a prompt that names a missing field is rejected, the duplicates collapse to one source of truth, and the team lead can reason about prompts like code
- **Narrative role:** anchors persona 4, the team lead drowning in prompt and config sprawl
- **What it teaches:** a schema-driven template layer makes prompts typed artifacts that cannot silently drift from the model
- **Intended impact:** the reader sees the invisible sprawl and the typed layer that ends the silent breakage
:::

### P5. The data engineer who became a human code generator

My job lately is defining the same model in SQL, then in the ORM, then in Pydantic, then in a JSON schema, rinse and repeat. Every new service starts with two days of copy-pasting the same validation and serialization glue, which is unpaid codegen with a data-engineering title on it. I've written the same User, Event, and Transaction models so many times I could do them in my sleep. I became a data engineer to solve interesting data problems, not to be a YAML, JSON, TypeScript, and Protobuf stenographer.

I keep seeing talks about elegant data architectures while I'm wiring JSON fields for the tenth time, and I wonder if maybe I'm just mediocre, or not senior enough to be trusted with the interesting work, which is why I get stuck with the boilerplate. The tooling made the same conceptual model need a different syntactic restatement in every layer, so my expertise got spent on the restating instead of on the data problems, one service at a time, until restating was the job. What gets me out is an intermediate representation that generates the SQL, the ORM model, the Pydantic model, the JSON schema, and the serializers from one definition. That's the codegen-and-export core of Scatter Model, and it's the relief developers adopt tools to get (VERIFIED demand, Perplexity Query 1, the tRPC/Zod/Prisma/Pydantic adoption is entirely about eliminating modeling the same data N times). People stay stuck because the boilerplate is steady and expected, so it never triggers the crisis that would justify changing the workflow, and pushing back on grunt work risks looking lazy. The price of staying is a career spent on glue, with the creeping doubt that this is all the work is. The price of leaving is letting one IR do the restating so the human does the interesting part (voice INFERRED, Perplexity Query 2; demand VERIFIED, Query 1).

:::animation p5
**ANIMATION p5: one definition restates itself everywhere**
- **What it shows:** a data engineer hand-transcribes the same User, Event, and Transaction model in SQL, then the ORM, then Pydantic, then JSON schema, a stenographer chained to boilerplate; then one IR definition fires and the SQL, the ORM model, the Pydantic model, the JSON schema, and the serializers all generate from it at once, and the engineer turns to the interesting data problems they were hired for
- **Narrative role:** anchors persona 5, the data engineer who became a human code generator
- **What it teaches:** one IR that generates every restatement frees the engineer from unpaid codegen to do real data work
- **Intended impact:** the reader sees the stenographer grind and the single-definition relief that ends it
:::

### P6. The world-builder who wants to model and play

I want to build a world, with characters, systems, economies, and the relationships between everything, and tune it the way you tune a strategy game until it feels right. What I have instead is spreadsheets and a database admin panel, and neither lets me see the world or play with it. Every detail I change means editing rows by hand, and there's no sense of a living model I can shape and watch respond. The tools that are visual are toys with no real structure underneath, and the tools that have real structure are command-line and code, so I'm always choosing between playable and powerful.

Modeling something I care about feels like data entry instead of design, and the friction kills the flow that made me want to build the world in the first place. Rich-model use cases (a game world, a simulation, a complex domain with many interacting entities) fall right in the gap the research names: ERD tools give a static diagram that isn't the operational truth, low-code tools give a soft proprietary schema with no typed depth, and nobody serves the person who wants both playability and a hard model (VERIFIED gap, Perplexity Query 1). The way out is ECS modeling made playable over a real typed IR, the Total Annihilation metal-planet canvas where you shape entities and components and agents help you tune them, which is the literal product vision of Scatter Model (VERIFIED, the seed). This persona is the aesthetic heart of the brand and its bridge to Depths of the Void, a sibling Looikos brand, and to the RPG-style persona profiles the ecosystem builds, because the same playable-world-modeling primitive serves both a business domain and a fictional universe. People settle for the playable-or-powerful tradeoff because no tool has offered both. Staying stuck keeps world-modeling tedious and the creative flow broken. Getting out means adopting a tool that treats the model as a world you play rather than a table you fill (voice INFERRED, Perplexity Query 2; gap VERIFIED, Query 1).

:::animation p6
**ANIMATION p6: playable and powerful, no longer a tradeoff**
- **What it shows:** a world-builder stands between two dead ends, a VISUAL toy with no real structure on one side and a POWERFUL command-line with no play on the other, forced to choose; then the two merge into a single steely-gray metal-planet canvas where entities and components and economies are shaped and tuned like a strategy game over a hard typed IR, agents helping tune, playable and powerful at once
- **Narrative role:** anchors persona 6, the world-builder who wants to model and play, the aesthetic heart of the brand
- **What it teaches:** ECS modeling made playable over a real typed IR ends the playable-or-powerful tradeoff every existing tool forces
- **Intended impact:** the reader feels the creative flow the brand restores and the bridge to fictional-world modeling
:::

## 5. The world model (run the PST framework)

The six personas share one loop of suffering, and modeling it as a single problem story turns the deck from a feature list into a PST read (problem, story, transformation). The method runs in four steps: echolocate the world, locate the problem, reconstruct the story, and design the transformation.

**Echolocate the world.** The buyer lives inside a developer-and-data ecosystem in motion. On one side is the relentless product pressure: features ship weekly, the schema is asked to absorb changes it was never designed for, and the model is always the thing under-resourced because it's invisible until it breaks. On another side is a tooling market that has fractured the single act of data modeling into a dozen syntactic restatements (database, ORM, backend type, frontend type, validation, API spec, prompt template) each owned by a different tool that doesn't share a source of truth with the others, so the developer is left as the human integration layer between them. On a third side is the rising agentic wave, where the market is rebuilding its modeling and semantic layers to be AI-native, which means the ground under the whole category is shifting toward the agent-native modeling Scatter Model is (VERIFIED trend, Perplexity Query 1). Read the way an M&A firm reads a target, the data model stands out as the highest-leverage and most-neglected artifact in the system, the place where a small early error compounds into the largest downstream cost, and that's why owning it is worth a brand.

:::animation 5a
**ANIMATION 5a: echolocating the fractured modeling world**
- **What it shows:** a pulse pings the developer-and-data world and the room reconstructs from echoes, relentless product pressure on one side asking the schema to absorb changes it was never designed for, a fractured tooling landscape on another where one act of modeling splinters into a dozen syntactic restatements each owned by a different tool, and a rising agentic wave on a third; at the center a single artifact glows, THE DATA MODEL, the most neglected and highest-value node where a small early error compounds into the largest cost
- **Narrative role:** anchors the echolocate step, reading the modeling ecosystem as an M&A target
- **What it teaches:** the data model is the most neglected and most consequential artifact, which is why owning it is worth a brand
- **Intended impact:** the reader stops seeing a tool market and locates the single high-value neglected node
:::

**Locate the Problem (the cycle of suffering).** The pain that arrives is concrete: the data model is wrong, or fragmented, or duplicated, and everything downstream inherits the error. In response a fear gets installed, and the developer's fear portfolio is distinctive because the profession runs on public competence. It holds three fears: the fear of the rewrite (the migration that corrupts production, the column rename that is a bomb defused with your teeth), the fear of looking junior (other devs claim beautiful end-to-end types, so my drift must mean I am not good enough), and the fear of being exposed as the one who approved the broken foundation. Those fears drive avoidance: the developer works around the bad model rather than fixing it, the founder builds the next feature on top of the rot rather than remodeling, the team lead greps for the right prompt rather than centralizing. Avoidance produces the unfavorable outcome (the schema gets worse and the sprawl grows), and the outcome produces shame, which rewrites I made a modeling mistake into I am a sloppy engineer, a mediocre data engineer, a non-technical fraud who can't define a table. The shame is buried under cope: blame the framework, blame the ORM, blame the deadline, blame the move-fast culture. The red line, the move forbidden, is accountability, because accountability means admitting that the modeling shortcut taken early was a choice and that the fear of looking slow for modeling properly is what drove it. The refusal opens a blind spot, the blind spot produces the next bad action (another layer added without a source of truth, another copy-pasted prompt, another hand-written serializer), and the loop closes and compounds into deeper technical debt and deeper self-doubt.

:::animation 5b
**ANIMATION 5b: the loop that turns a mistake into an identity**
- **What it shows:** the cycle turns through pain, the model is wrong or duplicated, then a fear portfolio installs, THE REWRITE, LOOKING JUNIOR, BEING EXPOSED AS THE ONE WHO APPROVED THE BROKEN FOUNDATION; those fears drive working around the bad model, the outcome worsens, and the shame station rewrites from I MADE A MODELING MISTAKE to I AM A SLOPPY ENGINEER, buried under copes blaming the framework and the deadline, while a red line marked ACCOUNTABILITY stays uncrossed
- **Narrative role:** anchors the locate-the-problem step, the developer's cycle of suffering
- **What it teaches:** the shame converts a modeling mistake into a verdict on the self, and the forbidden move is owning that the shortcut was a choice
- **Intended impact:** the reader sees why blaming the tooling is easier than accountability and where the exit is
:::

**Reconstruct the Story.** The belief structure under the loop is some version of modeling is overhead and shipping is the real work, or I will fix the data model later. The emotional-experience chain that built it is the developer-culture one: repeated experiences of being rewarded for shipping fast and visibly, and of being shamed (in code review, on a team, in public threads) for being slow or for getting something structurally wrong, hardened into a belief that velocity is the virtue and modeling is the tax. That belief drove actions (cut the modeling corner, assemble partial tools, defer the schema), the actions produced results, the results became habits, and the habits anchored into an identity where the engineer's worth is their throughput. The origin layer, where it gets intimate, is the move-fast wound: somewhere the person learned that being slow or careful was punished and being fast was rewarded, so taking the time to model properly feels like exposing themselves to the old punishment instead of like diligence. Most of them run from recognizing that the broken schema traces back to a fear they invested in, rather than to the market or the framework. On the Hawkins scale, a ranking of emotional states used here descriptively, shame, fear, and pride sit in the destructive band below the courage line, and the whole loop is fueled from there (VERIFIED framework usage, THE_PST_FRAMEWORK §5).

:::animation 5c
**ANIMATION 5c: velocity is the virtue, modeling is the tax**
- **What it shows:** a belief glows at the loop's root, MODELING IS OVERHEAD, SHIPPING IS THE REAL WORK, forged by repeated experiences of being rewarded for shipping fast and shamed in code review for being slow; underneath, a move-fast wound surfaces where being careful was once punished, so taking time to model properly feels like inviting the old punishment rather than doing diligence
- **Narrative role:** anchors the reconstruct-the-story step, the belief structure and its intimate origin
- **What it teaches:** the velocity-is-virtue belief is built from being rewarded for speed and shamed for care, so proper modeling feels like exposure
- **Intended impact:** the reader sees the origin the demographics discard and the wound the cope masks
:::

**Design the Transformation.** The bridge across hinges on courage, and Scatter Model's content has to make it crossable rather than a mugging. The first step is truth: the data model is the product, not the overhead. It's the most load-bearing artifact in the system, and treating it as a first-class playable thing is the leverage instead of the tax. The second is responsibility, owning the reaction rather than the circumstance: the developer didn't create the fractured tooling market, but they own whether they keep letting the fear of looking slow drive the corner-cut. The third is healing, which hurts the way remodeling a rotten schema hurts, because it means tearing through the identity knot that worth equals throughput and admitting the foundation was wrong, the same way the persona admits the first three months were a monument to bad decisions. The fourth is forgiveness, letting go of the original-sin verdict, forgiving the cut corner and the deferred model and the extra week not spent, and having the humility to learn from it, which opens the eyes to the new truth that being the architect of a clean model is a larger role than being the human integration layer between drifting copies. Scatter Model's offer is calibrated to that bridge: the visual studio removes the table-thinking barrier for the domain expert, the single IR removes the duplication for the developer, the propose-review-with-blast-radius loop removes the migration terror for the founder, the schema-driven templates remove the sprawl for the team lead, and the codegen removes the boilerplate for the data engineer. Most of the content lives in the negative band, the drift and the dread and the shame, because that's where the audience lives, with the playable, agent-tended, single-source-of-truth world shown as the reachable other side. That's the echolocation approach applied to the person whose data model is quietly breaking everything they build.

:::animation 5d
**ANIMATION 5d: the crossable bridge to the model-as-product**
- **What it shows:** a developer crosses a bridge from a near bank of drift and dread to a far bank where the model is a playable agent-tended source of truth, built in four planks, TRUTH the data model is the product, not the overhead, RESPONSIBILITY own whether the fear of looking slow drives the corner-cut, HEALING tear through the worth-equals-throughput knot, FORGIVENESS release the original-sin verdict on the cut corner; on the far bank the person stands as the architect of a clean model rather than the human integration layer between drifting copies
- **Narrative role:** anchors the design-the-transformation step, the crossable bridge
- **What it teaches:** the transformation reframes the model as the product and treats it as a first-class playable thing rather than a tax
- **Intended impact:** the reader sees the growth cycle as a concrete crossing that turns a janitor into an architect
:::

## 6. Competitive and market read (the alpha / third door)

The competitive field is dense at the edges and empty at the center, the same shape as the WikiDesignCo market in a different domain. Mapped by cluster and by what each cluster refuses to do, it shows where the opening is.

**Who else does this, and what they won't do.** The field holds four clusters plus one convergent threat (VERIFIED, Perplexity Query 1). The schema and ORM tools (Prisma, Hasura, dbt, Supabase) each unify one or two layers and stop. Prisma unifies the database schema and the TypeScript client but has no visual modeling, no frontend forms, no template layer, and a Prisma-specific schema rather than a general IR. Hasura turns a database schema into a GraphQL API but keeps the database primary and brings no rich application model. dbt owns the analytics semantic layer (metrics and dimensions) but not transactional app schemas, and it's code-and-YAML, not visual. Supabase exposes raw Postgres with auto-generated APIs but offers no higher-level typed IR and no playability. The low-code and internal-tools platforms (Retool, Airtable, Baserow, Budibase, Appsmith) are visually playable but their schema is soft and proprietary, not a typed IR, and they generate no Pydantic, Zod, or TypeScript that the rest of a stack can consume, so they're the backend for an app rather than the source of truth for a stack. The type-safe codegen tools (Pydantic, datamodel-code-generator, Zod, tRPC, OpenAPI codegen) unify two or three layers each but are one-directional, code-centric, and own no visual modeling and no template layer. The prompt and template managers (the PromptOps tools, Humanloop, PromptLayer) version prompts but almost never tie them to a typed schema model, so they live beside the data models rather than as a typed consequence of them. Across all four clusters, the consistent refusal is the same: nobody unifies the database schema, the backend types, the frontend types and forms, the prompt and content templates, and the config files from one intermediate representation, and nobody makes the model playable or lets agents maintain it (VERIFIED, Perplexity Query 1).

:::animation 6a
**ANIMATION 6a: four clusters, each stopping short**
- **What it shows:** four clusters stand as labeled boxes, SCHEMA AND ORM TOOLS, LOW-CODE AND INTERNAL-TOOLS, TYPE-SAFE CODEGEN, PROMPT AND TEMPLATE MANAGERS, each unifying one or two layers and lighting only its slice; a full spectrum of layers runs above them, database, backend, frontend and forms, templates, configs, and no single cluster reaches across all of it or makes the model playable and agent-maintained
- **Narrative role:** anchors the §6 competitive read, the four clusters and their shared refusal
- **What it teaches:** every cluster unifies one or two layers and none unifies all of it from one IR or makes it playable
- **Intended impact:** the reader sees the field as dense at the edges and empty at the center
:::

**The convergent threat.** Pydantic AI is repositioning Pydantic as an end-to-end AI-engineering stack where typed models structure agent inputs and outputs, and the BI vendors (dbt's semantic layer, Holistics, Rill) are rebuilding their semantic layers to be agent-native, so the agent-native-modeling space is being entered from several directions at once (VERIFIED, Perplexity Query 1). The space is being approached and isn't yet occupied: each entrant owns one slice (Pydantic AI owns agents on top of existing models, dbt owns analytics semantics), and none of them builds and maintains the models themselves visually and propagates them across infrastructure and behavior. Against Pydantic AI specifically, the separation drawn in the software section holds: Pydantic AI builds agents on the models a team already has, and Scatter Model builds the models. Riding the Pydantic wave stays both the safer go-to-market and the more defensible position (VERIFIED strategic read, Perplexity Query 1).

:::animation 6b
**ANIMATION 6b: the space approached, not occupied**
- **What it shows:** several entrants advance on the agent-native-modeling space from different directions, PYDANTIC AI owning agents on top of existing models, DBT and the BI vendors rebuilding semantic layers to be agent-native, each planting a flag on one slice; the center, BUILD AND MAINTAIN THE MODELS THEMSELVES, VISUALLY AND ACROSS EVERY BACKEND, stays open and unclaimed, and Scatter Model steps into it
- **Narrative role:** anchors the §6 convergent-threat read, honestly named
- **What it teaches:** the space is being approached from several directions but not occupied, each entrant owning one slice and none building the models themselves
- **Intended impact:** the reader sees the competitive pressure named honestly and the open center that remains
:::

**The third door.** Alpha, the opening this section maps, is the thing competitors know about and won't do, and Scatter Model's alpha is the connected combination of four moves that everyone ships separately: the weaponized-autism modeling depth (every detail of the model playable and tunable), the talk-to-agents propose-review loop, the single IR projecting across every backend with per-backend overrides, and the ownership of the dynamic-template layer as a typed consequence of the model. Any one of these exists somewhere; the four as one connected primitive exist nowhere, and the reason competitors won't connect them is structural. The schema tools are organized around code-first developer workflows and won't build a playable visual layer; the low-code tools are organized around non-developers and won't build a hard typed IR; the prompt tools are organized around AI-team workflows and won't reach into database schemas. Connecting the four requires a builder willing to do the unglamorous depth across all of them, which is the weaponized-autism-to-Pydantic thesis the brand is named for.

:::animation 6c
**ANIMATION 6c: the four moves nobody connects**
- **What it shows:** four capabilities float apart, WEAPONIZED-AUTISM MODELING DEPTH, the TALK-TO-AGENTS PROPOSE-REVIEW LOOP, the SINGLE IR ACROSS EVERY BACKEND, OWNERSHIP OF THE TYPED TEMPLATE LAYER, each existing somewhere in the field; they fuse into one connected primitive that the incumbents will not build because the schema tools will not go visual, the low-code tools will not go hard-typed, the prompt tools will not reach into schemas
- **Narrative role:** anchors the §6 third-door alpha, the connected combination of four moves
- **What it teaches:** the alpha is the four moves connected as one primitive, which competitors will not do because each is organized around a workflow that forbids it
- **Intended impact:** the reader locates the specific edge and the structural reason it stays unbuilt
:::

**Wardley evolution and the own-versus-rent call.** A Wardley map places each capability on a line from novel (genesis) to commodity. ORMs, migrations, and schema validation sit at product-to-commodity, so Scatter Model rents and harvests them instead of custom-building, using Pydantic and the existing codegen tools as components. The playable, agent-native, unified IR with the typed template layer is genesis-to-custom: novel, differentiating, and load-bearing, the textbook own-and-build capability where the alpha lives. The visual canvas is genesis and gets probed before heavy investment, because of the Git caution from the software section, so the safe path builds the IR and the codegen first and treats the playable canvas as the differentiating layer added on a proven core (VERIFIED caution, Perplexity Query 1).

:::animation 6d
**ANIMATION 6d: own the IR, rent the ORM, probe the canvas**
- **What it shows:** a Wardley evolution axis; on the commodity right sit ORMs, migrations, and schema validation stamped RENT AND HARVEST with Pydantic and existing codegen used as components; on the genesis-leaning left sits the playable agent-native unified IR with the typed template layer stamped BUILD AND OWN; a separate probe marker sits on the visual canvas labeled FRONT-END OVER A GIT-NATIVE TEXT IR, TEST BEFORE HEAVY INVESTMENT
- **Narrative role:** anchors the §6 Wardley own-versus-rent call
- **What it teaches:** the brand rents the commodity tools, builds the unified IR, and probes the playable canvas as a layer over a Git-native text IR
- **Intended impact:** the reader sees exactly what to own, what to rent, and what to test before committing
:::

**Market size and demand signal.** Sizing it takes triangulation, because there's no clean total addressable market (TAM) for unified-IR modeling. The addressable space is the intersection of developer tools (commonly sized $50-80B), data and analytics software (north of $100B), and low-code and internal tools (commonly sized $30-70B at 20-30% CAGR), and even low single digits of that intersection is a multi-billion opportunity (VERIFIED directional, Perplexity Query 1). The demand is revealed by adoption: tRPC, Zod, Prisma, and Pydantic are all adopted specifically to stop modeling the same data N times, which is direct market validation of the core wedge (VERIFIED, Perplexity Query 1). The category comps confirm the ceiling: Airtable at a reported $11B, Retool toward $6-8B, Hasura around $1B (VERIFIED market-reported, Perplexity Query 1). Proven demand, an unbuilt unified fix, and an agent-native wave moving toward the brand add up to the best market shape a young brand in this category can hope for.

## 7. The build (what this brand needs, where Track R feeds Track P)

Scatter Model is concept-stage, so the build section is more INFERRED than WikiDesignCo's, but the shape is well-determined because the brand is the productization of a discipline and a stack the ecosystem already uses.

**What it is built from.** The IR core is Pydantic V2, the typed intermediate representation that everything projects from (VERIFIED that Pydantic-as-IR is the ecosystem discipline). The modeling engine is the eight-step problem-story-to-ECS-catalog derivation, the proven internal practice that turns a domain into entities and components. The visual studio is a Three.js and React canvas rendering the Total Annihilation steely-gray-metal-planet aesthetic, the playable layer over the text IR. The agent loop is LangGraph for the propose-review workflow with PydanticAI and the Claude Agent SDK for the agents inside the nodes, structured so an agent proposes a model edit and the system computes and shows the blast radius (the migrations, the API changes, the UI changes) before a human accepts (VERIFIED design requirement, Perplexity Query 1). The dynamic layer is Jinja for the schema-driven templates, with every template's variables validated against the IR. The export layer is the per-backend projection: Pydantic-IR to database schema, to FastAPI models, to Zod, to TypeScript types, with the per-backend overrides that keep the single IR from collapsing to a lowest common denominator (VERIFIED architecture, Perplexity Query 1).

:::animation 7a
**ANIMATION 7a: the stack from IR core to every backend**
- **What it shows:** a vertical stack assembles, PYDANTIC V2 as the typed IR core at the base, the eight-step DERIVATION ENGINE turning a domain into entities and components above it, a THREE.JS metal-planet visual studio as the playable layer, a LANGGRAPH propose-review agent loop, a JINJA schema-driven template layer, and a per-backend EXPORT layer projecting into database, FastAPI, Zod, and TypeScript with manual overrides where a target demands them
- **Narrative role:** anchors the top of §7, what the brand is built from
- **What it teaches:** the build is a layered stack from a Pydantic IR core out through derivation, playability, agents, templates, and per-backend export
- **Intended impact:** the reader sees the whole architecture as concrete layers rather than a vague platform
:::

**The hexagonal discipline.** The platform has one IR core and many surfaces. The model operations live in a core that never imports a transport, and the visual studio, the MCP server, the CLI, the SDK, and the codegen engine are all thin adapters over it. That's the same one-core, many-surfaces pattern the ecosystem runs on, and it's the mechanical defense against disconnected copies of the truth, in a brand whose entire job is to be the single source of truth: if the IR is the one authoritative representation and every surface references it rather than copying it, then the brand can't itself reproduce the model-the-data-N-times problem it exists to solve. The recursion is pleasing: the data-modeling platform has to be the cleanest example of single-source-of-truth modeling itself, and the hexagonal core is how it earns that.

:::animation 7b
**ANIMATION 7b: the modeling platform models itself**
- **What it shows:** the IR core sits at the center and every surface, the visual studio, the MCP server, the CLI, the SDK, the codegen engine, reaches in to reference it rather than keeping its own copy; a recursive loop shows the platform describing its own entities, components, and templates with the same IR, so the data-modeling tool is itself the cleanest single-source-of-truth model, unable to reproduce the model-it-N-times problem it exists to solve
- **Narrative role:** anchors the §7 hexagonal discipline, the models-of-models recursion
- **What it teaches:** the brand must itself be the cleanest example of single-source-of-truth modeling, which the hexagonal core is how it earns
- **Intended impact:** the reader sees the platform practicing the discipline it sells, which is the credibility test
:::

**The data models.** Scatter Model is the meta case: it's the data-model platform, so its own data models are models-of-models, the schema for describing entities, components, relationships, constraints, projections, and templates. That's Pydantic-as-IR pointed at itself, the weaponized-autism-to-Pydantic thesis taken to its conclusion. The ECS shape is native here rather than imposed, because the brand's whole pitch is ECS-modeling-made-playable.

**The agent roster the domain needs.** The build groups the work into three feature factories, each a set of harnesses plus a gateway. The model-editor factory runs the visual studio and its round-trip to the text IR. The derivation-and-update factory runs the eight-step derivation plus the propose-review-with-blast-radius agent loop. The dynamic-template factory runs the schema-driven Jinja layer and the codegen-and-export engine, and it may split into two factories as scope grows. All three use the modular harness pattern from Harness V2 `HARNESS_V2_CONSOLIDATED_BRIEF.md`.

:::animation 7c
**ANIMATION 7c: three factories on the IR core**
- **What it shows:** three feature factories take stations around the IR core, a MODEL-EDITOR factory running the visual studio and its round-trip to the text IR, a DERIVATION-AND-UPDATE factory running the eight-step derivation and the propose-review-with-blast-radius loop, a DYNAMIC-TEMPLATE factory running the schema-driven Jinja layer and the codegen-and-export engine; each is a set of harnesses plus a gateway, the update factory glowing as the trust loop
- **Narrative role:** anchors the §7 agent roster, the three feature factories the domain needs
- **What it teaches:** the domain decomposes into three factories on the IR core, with the propose-review loop as the trust mechanism
- **Intended impact:** the reader sees the build as a maintainable roster of factories over one core
:::

**The medallion tiers.** The bronze-to-gold quality ladder data teams use applies here to model maturity instead of a knowledge corpus: a bronze draft model, a silver validated-and-typed model, a gold model with tests and provenance and an accepted agent-edit history, and a diamond model that's the certified source of truth for a domain with a governed review-and-certification loop. That loop is the stewardship the service angle sells, so the medallion tiering and the stewardship model are the same idea (VERIFIED stewardship framing, Perplexity Query 1; the medallion-to-model-maturity mapping is INFERRED).

:::animation 7d
**ANIMATION 7d: draft model to certified source of truth**
- **What it shows:** the medallion stack lights in order applied to model maturity, BRONZE a draft model, SILVER a validated-and-typed model, GOLD a model with tests and provenance and an accepted agent-edit history, DIAMOND a certified source of truth for a domain with a governed review-and-certification loop turning beside it; the loop and the tiers are drawn as the same idea, the stewardship where the durable value sits
- **Narrative role:** anchors the §7 medallion tiers applied to model maturity
- **What it teaches:** a model climbs from draft to certified source of truth through a governed stewardship loop, which is where the durable value sits
- **Intended impact:** the reader sees the data-quality ladder as the same thing as the ongoing stewardship relationship
:::

**Where Track R feeds Track P.** Track R, the research pass over open-source repos that feeds this brand work (Track P), hasn't started, so the specific OSS harvest targets are OPEN. The shape of the need is nameable: Scatter Model will want the best harvested patterns for codegen-across-backends (whatever the Track-R schema and codegen repos teach), for the visual-graph-editing canvas (the Track-R graph-viz and node-editor repos), for the agent propose-review loop (shared with the harness and with WikiDesignCo's agentic stack), and for the template and prompt-management layer (shared with Story Factory). Once those repo reports exist `stack-recon/repos/<repo>.md`, the value rubric that sets each brand's priority ranks the combined wish-list and the specific capabilities slot in here. Naming the shape and marking the source OPEN is the no-fabrication discipline.

:::animation 7e
**ANIMATION 7e: named harvest shapes, source held open**
- **What it shows:** four dashed sockets marked OPEN wait for Track R, codegen-across-backends patterns, a visual graph-editing canvas, the agent propose-review loop shared with the harness, the template and prompt-management layer shared with Story Factory; the sockets are clearly outlined and empty rather than filled with invented repos, the source held open until the repo list lands
- **Narrative role:** anchors the §7 Track-R-feeds-Track-P paragraph, the named harvest shapes
- **What it teaches:** the brand names the capability shapes it will harvest and marks the specific repos open rather than fabricating them
- **Intended impact:** the reader trusts the build to state its own gaps and reuse shared primitives
:::

## 8. Priority read (feeds the value rubric)

Scatter Model is a foundational primitive (the intermediate representation every other brand's software angle is built on) but it's less immediately gating than WikiDesignCo, and the distinction matters for sequencing. The discipline already runs internally through the data-architecture derivation engine, so the ecosystem isn't blocked on Scatter Model the way it's blocked on the next phase of WikiDesignCo's metagraph, the shared knowledge graph; the productized brand is a force-multiplier that makes modeling faster and cheaper and sellable, not a substrate other brands can't ship without. On the ecosystem's map of which brands depend on which promises, it's a high-leverage node whose promise the internal discipline already partly keeps, which lowers its blocking priority and leaves its leverage high.

:::animation 8a
**ANIMATION 8a: high pull, promise already partly kept**
- **What it shows:** Scatter Model sits as a node with many brands' software angles hanging off it, its pull high; but a portion of its promise already glows kept, because the data-architecture derivation discipline runs internally today, so unlike WikiDesignCo's metagraph the ecosystem is not blocked waiting on it, and the node reads as a force-multiplier rather than an unavoidable substrate
- **Narrative role:** anchors the §8 opening, the high-pull but partly-kept-promise position
- **What it teaches:** the brand's pull is high while its blocking-priority is lower because the discipline already runs internally
- **Intended impact:** the reader places the brand as a force-multiplier to sequence rather than a gate to clear first
:::

Readiness is the real constraint. Scatter Model is concept-stage with no standalone repo, so its readiness is well below its leverage, and the priority read holds that gap explicitly rather than letting the strong thesis imply the brand is near-shippable.

The first-pass tiering, capability by capability:

- **Next (build and own, gated on harness maturity):** the playable, agent-native, unified Pydantic-IR with the propose-review-with-blast-radius loop. It's genesis-stage, load-bearing, the alpha competitors won't connect, and high leverage across every brand's software angle. It's Next rather than Now because it's gated on the Harness V2 agent stack being mature enough to run the propose-review loop reliably, and on a read of the convergent competitors (Pydantic AI) before the differentiation is committed. Because it shapes many future decisions, it's scored on its discounted future value.
- **Next (the differentiating layer):** the schema-driven dynamic-template engine, the typed Jinja layer, which depends on the IR core and on a narrow initial wedge (start with transactional emails and type-correct dashboards, not every template), following the narrow-wedge caution from the software section.
- **Watch (probe before heavy investment):** the playable Three.js visual canvas. It's the aesthetic differentiator and the most novel surface, but it has to be a front-end over a Git-native text IR, so it routes to a probe (build the IR and codegen first, prototype the canvas on the proven core) rather than a commitment. It's genesis-stage, low-confidence, and high-potential, the profile the rubric routes to a hands-on test.
- **Leave (rent instead of custom-building):** ORMs, migrations, schema validation, the existing codegen tools. They're commodities, so Pydantic and the existing tools get used as components.

:::animation 8b
**ANIMATION 8b: four verdicts by capability**
- **What it shows:** the brand's capabilities sort into trays; NEXT holds the unified playable agent-native IR with the propose-review loop and, beside it, the schema-driven template engine on a narrow initial wedge; WATCH holds the playable Three.js canvas routed to a probe over a Git-native text IR; LEAVE holds ORMs, migrations, and schema validation stamped RENT; each tray carries the reason it landed there
- **Narrative role:** anchors the §8 capability-by-capability tiering
- **What it teaches:** the IR and template engine are Next gated on harness maturity, the visual canvas is probed, and the commodity tools are rented
- **Intended impact:** the reader sees a differentiated priority call per capability rather than one flat verdict
:::

The read then runs the seven-sins check: seven ways an analysis fools itself, each named for a deadly sin. Against pride, or look-ahead bias, it scores the brand as concept-stage and the IR unification as a bet instead of treating it as shipped. Against envy, or survivorship bias, the failure modes sit in the deck beside the upside (the lowest-common-denominator IR risk, the playability-fights-Git risk, the convergent Pydantic AI threat). Against gluttony, or overfitting, the enthusiasm is capped to the proven internal discipline and isn't inflated by the feature surface. Against sloth, or transaction cost, the build friction (the per-backend projection complexity, the agent-loop reliability) is named as the gate. Against wrath, or regime blindness, the read assumes the 2026 agent-native-modeling regime, which is moving toward the brand, and flags that the same movement brings convergent competitors. Against lust, or capacity delusion, Scatter Model is one foundational build with a narrow initial wedge, with no attempt to own every template surface at once. Against greed, or fat-tail risk, the tail risk is Pydantic AI or a low-code incumbent reaching the unified-IR space first, which is why the differentiation has to be read and committed deliberately, scored on its long-run value instead of adopted by rule. The dependency that matters for sequencing is that Scatter Model's leverage is high and its readiness is low, so it's a strong Next rather than a Now, and it should follow the harness maturing rather than lead it.

:::animation 8c
**ANIMATION 8c: strong Next, sequenced behind the harness**
- **What it shows:** a status dial reads NEXT rather than NOW, held there by two gates, HARNESS V2 MATURE ENOUGH TO RUN THE PROPOSE-REVIEW LOOP and READ THE CONVERGENT PYDANTIC AI LANDSCAPE; the brand's high pull glows behind the gates, and an arrow shows it sequenced to follow the harness maturing rather than lead it
- **Narrative role:** anchors the §8 verdict, the strong-Next sequencing recommendation
- **What it teaches:** high pull plus low readiness makes it a strong Next whose sequencing follows the harness rather than leads it
- **Intended impact:** the reader leaves with a clear sequencing call rather than a vague later
:::

## 9. The brand's own nine-rung position

Scatter Model as an enterprise, distinct from the research lane at the top of the deck.

:::animation 9a
**ANIMATION 9a: the brand as one derivation chain**
- **What it shows:** the nine rungs stack from Purpose at the rails down through Mission, Objective, Initiative, Project, Task, Action, Decision, Data, to Event, each rung filling with Scatter Model's own content, own the data-modeling primitive, end the model-it-N-times tax, ship the IR core and codegen and propose-review loop, derive one domain's ECS catalog, run one codegen export, accept one agent-edit proposal with its blast radius, log a model published and a template rendered, so the whole brand reads as one chain from purpose to captured event
- **Narrative role:** anchors §9, Scatter Model modeled as an operating business for the metagraph
- **What it teaches:** the brand is a full nine-rung derivation from purpose to a logged runtime event, not a pitch
- **Intended impact:** the reader sees the brand resolve into a governable chain the metagraph can hold and query
:::

- **Purpose (rails):** own the data-modeling primitive of the ecosystem. Be the single typed source of truth from which every schema, type, form, config, prompt, and content template is generated, and make modeling that source playable and agent-native.
- **Mission (1):** end the model-the-same-data-N-times tax and the schema-drift dread, for the developer, the founder, the domain expert, and the data engineer, by making one typed IR the playable, agent-tended source of truth across the stack.
- **Objective (2):** the measurable cycle outcome, the IR core plus codegen plus the propose-review agent loop shipped and projecting cleanly into Postgres, FastAPI, Zod, and TypeScript, with the first paying data-architecture-as-a-service engagements live.
- **Initiative (3):** Pydantic-IR-becomes-a-platform, the productization of the internal derivation discipline into a sellable brand.
- **Project (4):** the modeling studio plus the codegen engine plus the dynamic-template layer, each with its own scope and definition of done; the playable canvas is a gated later project.
- **Task (5):** a unit a single agent executes, for example deriving one domain's ECS catalog, or wiring one per-backend projection.
- **Action (6):** an atomic operation, for example an agent proposes one model edit, the system computes one blast-radius preview, the codegen runs one export, one schema-driven template renders.
- **Decision (7):** the choice points, for example which backends the IR projects to and where a manual override is needed (heuristic: per-backend constraints; authority: the modeler), and whether an agent-proposed edit is accepted (heuristic: the blast-radius preview; authority: the human reviewer).
- **Data (8):** the ECS records the platform produces, ModelEntity, Component, Relationship, Projection, Template, AgentEditProposal, each a typed Pydantic-IR record (the meta case, models of models).
- **Event (9):** the real occurrences captured, a model published, a codegen export run, an agent-edit proposal accepted with its blast radius, a dynamic template rendered, a client domain modeled and delivered.

## 10. Sources

Evidence-tag legend: VERIFIED (the seed, the established Pydantic-IR discipline, market data, or confirmed comp), INFERRED (reasoned from the seed or the patterns, not directly confirmed; the brand is concept-stage so much of the build and revenue modeling is INFERRED), OPEN (acknowledged gap, routed to a probe or to Track R).

**Internal sources (VERIFIED):**
- `LOOIKOS_ECOSYSTEM.md` §Category 1 (the Scatter Model seed verbatim: Pydantic-IR-becomes-a-platform, ECS-made-playable, the talk-to-agents loop, the Total Annihilation aesthetic, ownership of the Jinja/dynamic layer, the Pydantic-to-Zod/TS split; plus the three-angle model and the $10M-floor framing).
- The Scatter Model name origin (weaponized-autism-to-Pydantic) from the ecosystem memory notes.
- The data-architecture derivation discipline (the eight-step problem-story-to-ECS-catalog) as the existing internal practice the brand productizes (VERIFIED that the discipline is in use; no standalone Scatter Model repo found, searched and confirmed absent).

**Framework and sibling docs (cross-referenced, not copied, per the-disconnection):**
- `THE_PST_FRAMEWORK.md` (the suffering-loop and growth-cycle architecture applied in §4 and §5; the Hawkins scale used descriptively).
- `HARNESS_V2_CONSOLIDATED_BRIEF.md` (the custom-modular-composable-harness and feature-factory pattern, referenced).
- `THE_FLOOR.md` (the shared-floor customer-success operating model for the service angle).
- Sibling brand decks referenced: `wikidesignco.md` (the IR consumer), Story Factory (the structured-document sibling of the generation problem), Depths of the Void (the world-building consumer of the playable-modeling primitive). Referenced, not copied.
- `symphony/stack-recon/VALUE_RUBRIC.md` (the §8 tiering, Powell routing, the seven-sins gate).

**Perplexity queries (verbatim, sequential):**
- Query 1 (market + competitors + alpha): "Context: I am researching the market for a developer/data-platform product that turns data modeling into an interactive, visual, agent-native experience ... one typed data model (Pydantic V2 as IR) ... generates schemas, TS/Zod types, forms, configs ... visually 'play with' the model ... owns the dynamic-generation layer ... [players, TAM, model-it-three-times pain, M&A comps; hypothesis pressure-test]." Key citations: pydantic.dev, github.com/pydantic/pydantic-ai, holistics.io (agentic modeling), rilldata.com (data modeling for the agentic era), and the dev-tool funding figures (Airtable, Retool, Hasura, Prisma, Supabase).
- Query 2 (Lexicon of Pain / Voice of Customer): "I am building developer/data-practitioner personas and need the Voice of Customer in their OWN WORDS ... Hacker News, Reddit, Stack Overflow, GitHub issues ... [five developer/operator situations]." Honesty flag: the source returned constructed-but-realistic phrasings (flagged as such) corroborated by real HN and dev-emotion threads (news.ycombinator.com, dev.solita.fi/emotional-code, codingwithempathy.com, stackoverflow.blog on developer tool attachment), so all §4 persona language is tagged INFERRED representative voice, not documented quotes.

**Coverage statement.** VERIFIED on the seed, the established Pydantic-IR discipline, the competitive structure, and the category comps (cited market data). INFERRED on the brand's build specifics, the revenue and service modeling (concept-stage, no live receipts), the medallion-to-model-maturity mapping, and the persona voice. OPEN on the specific Track-R OSS harvest targets (pending Andy's repo list), the WikiDesignCo-specific customer count standard applied here, and the eventual exact valuation (no ARR exists yet).