Scatter Model

Self-containment note (R20): external documents referenced herein are vendored under canon/ as of 2026-07-05. Citations below are the historical record of what this report read at authoring time and are left verbatim; to follow one as a live pointer, resolve the doc under canon/.

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

Scatter Model is the brand that turns the Pydantic-as-intermediate-representation discipline into a product, and the data-modeling primitive of the whole Looikos ecosystem. The plain version: you define a domain once as typed objects, 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, and you shape and explore that model visually, the way you would world-model when building a role-playing game, while conversational agents go and update the model for you (you keep what you like, you talk to them and they adjust what you do not).

It 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 the 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.

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.

For whom: the builder, the operator, and the domain expert who need a clean typed world-model behind every solution and do not want to hand-write or hand-reconcile it five times. Scatter Model is concept-stage today, with no standalone repo, though the discipline it productizes already runs across the ecosystem through the data-architecture derivation engine, so the brand is the product wrapper around a proven internal practice rather than an untested idea.

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 read confirms each is a real and largely unoccupied position.

The first is that "ECS data architecture made playable" is a genuine 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 Total Annihilation aesthetic, the 1990s steely-gray metal-planet vibe, 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 is a real differentiator because, as the market read shows, the visual tools that exist (ERD diagrammers) are not the operational source of truth and do not round-trip, while the playable low-code tools (Airtable, Retool) have soft proprietary schemas with no typed IR underneath. Scatter Model's playability is meant to sit over a hard typed IR, which is the combination 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 market read flags exactly 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. Scatter Model's keep-it-or-talk-to-them-and-adjust loop is precisely that proposal-and-review pattern stated in Andy's own words, which is the validated way to make agent-native modeling trustworthy rather than reckless.

The third is why owning the Jinja and dynamic-generation layer makes Scatter Model the connective tissue of the ecosystem rather than just another 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 does not exist, a generated email can never drift from the model, and a form regenerates when the model changes. The market read names this as a real and 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. 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.

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 market read sharpens the caveat: one IR for literally every backend risks becoming either a lowest-common-denominator model that loses expressiveness or a complex DSL nobody enjoys, so the honest architecture is a core IR (entities, fields, relationships, constraints) plus per-backend projection layers with manual overrides where a target's constraints demand them. Scatter Model is the consumer-facing sibling of the discipline WikiDesignCo's platform runs on (WikiDesignCo uses Pydantic-as-IR internally; Scatter Model is the brand that turns it into a product) and a peer of Story Factory, which owns the structured-document side of the same generation problem (both referenced, not copied, per the-disconnection). ECS data modeling exists to build solutions, and Scatter Model is where the data model and everything built on it connect.

3. The three-angle valuation (the core of a self-standing brand)

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 is the reason the category's comps run 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 the agent-native access pattern (agents reading and proposing model edits through MCP, codegen runs, dynamic-template renders). Because Scatter Model is concept-stage with no live revenue, the throughput numbers here are projections, 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 exactly that ARR quality. 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.

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.

The M&A and valuation comps for this category are strong, named, and post-2020. 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. 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.

Run the $10M floor against those comps and the same conclusion holds as for any Looikos brand: $10M is what the service angle alone floors at, and a tool sitting in a category whose comparables run from hundreds of millions to eleven billion has a software-angle ceiling far above that. The honest caveat is the concept-stage discount. Scatter Model has no ARR yet, so it is 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.

The market-maker's tri-level read closes it. 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 genuine 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 precisely the wave Scatter Model rides rather than fights. Sentiment is moving toward exactly the thing the brand is, which is 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 core-one-surfaces-many pattern the whole ecosystem runs on: 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.

The dynamic-generation engine (the Jinja layer: prompt templates, programmatic email and content, forms, configs) is a distinct monetizable surface in its own right, and the market read confirms it is currently sold as a separate category entirely (the prompt-ops tools, the template managers), which means Scatter Model's version, where templates are typed consequences of the model rather than a tool beside it, is a differentiated product rather than a feature.

The platform decomposes into feature factories with clean domain boundaries, each maintained largely by its own agent harness. Four are legible from the seed and the market read. The model editor factory (the visual ECS studio and its round-tripping to the text IR). The agent-update factory (the propose-review-accept loop, with the blast-radius preview the market read flags as essential, 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 (the schema-driven Jinja layer with validated variables). The codegen-and-export factory (the per-backend projection layers). Each is a set of harnesses plus a gateway harness specialized for its domain, which is the same custom-modular-composable-harness pattern the Harness V2 build provides (referenced from, not copied).

The market read sharpens the software architecture in three ways that the deck builds in honestly rather than glossing. First, one IR for every backend is riskier than it sounds, because a single model that must satisfy SQL, NoSQL, search indexes, and event streams tends to collapse to a lowest common denominator or bloat into a DSL nobody enjoys, so the right shape is a core IR plus per-backend projection-and-mapping layers with manual overrides. Second, visual playability must not 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. 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. These are not weaknesses in the thesis; they are the engineering shape that makes the thesis shippable, and a deck that omitted them would be selling an empty idea.

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. 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 rather than fighting it: it is Pydantic-IR-centric, so it slots into the Python ecosystem and extends Pydantic AI rather than competing with it, which is both the safer go-to-market and the more defensible position.

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.

The target operator is the Looikos canonical, resolved to this domain: the sub-25-employee master-complex who has deep, real, non-replicable domain expertise but cannot turn it into a working data structure. The market read locates this person precisely. 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. These are people who are masters of their domain and not of data architecture, which is exactly the master-complex profile, and the derivation engine plus the visual studio is the thing that bridges their expertise into a clean model without them having to become data engineers.

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 pre-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. The accessible-product tier sits around the $1-2k/month band and the retainers in the $2-12k+ band, the standard economics, and the service angle floors around $1M/month at the ecosystem-standard 100-to-250 retainer customers.

The commodity work beneath the premium engagements (routine schema cleanups, simple migrations) gets partnered to the sister affiliate network of specialists, so service at scale is a network rather than a headcount problem, and the human operating model that runs the relationship is the shared-floor customer-success model (referenced from, not copied). The relationship is the irreducibly human part, and the modeling engine exists to make one person capable of delivering it at portfolio scale. There is one service-angle subtlety worth naming: data architecture is a deliverable a client may perceive as one-time, 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), which the market read independently identifies as where the durable value sits, in the governed review-and-certification loop rather than the one-shot model.

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

Six personas, first person, at world-experience depth, carrying the pain in close-to-real developer and operator language. The Lexicon of Pain below is representative voice: the voice-of-customer research returned constructed-but-realistic phrasings (it flagged them as such) corroborated by real Hacker News and dev-emotion threads, so the phrases are tagged as representative, not as documented quotes. The bias is toward the negative emotions, because that is 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).

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. It is not type safety 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 am basically a type janitor, and production is a bug lottery where the frontend thinks price is a string, the backend thinks it is a float, and the database has it nullable.

How it hits my status: when a field mismatch slips through and breaks in prod, people think I am sloppy, even though the process is fundamentally broken. How I got here: 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. What it takes to get out: one intermediate representation that all the layers project from, which is precisely what Scatter Model is, and the reason the brand exists is that the market has proven the pain by adopting four partial fixes and still drifting. Why most stay stuck: the duplication is normalized, everyone does it, so it reads as the cost of doing business rather than a solvable defect. The cost of staying stuck is the slow erosion of trust in my own system, never fully believing a deploy, and the quiet fear that other devs have beautiful end-to-end types so maybe I am just not good enough. The cost to get out is adopting a single source of truth and letting it generate what I used to hand-reconcile.

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 do not 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 is way too late now.

How it hits my status and my life: I approved this schema, so admitting it is broken is admitting I screwed up the foundation, and investors and customers think we are more solid than we are. How I got here: 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. What it takes to get out: a way to remodel the domain cleanly and migrate toward it with the blast radius visible before each change, which is exactly the propose-review-with-blast-radius loop Scatter Model is built around. Why most fail: 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. The cost of staying stuck is that every new feature is eighty percent fighting legacy and twenty percent real work. The cost to get out is the identity hit of admitting real engineers get the foundation right up front, and choosing to fix it anyway.

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 do not. I think in how the work actually happens. I can explain the rules to a human in five minutes and I cannot 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 would not need a no-code tool. I keep telling the devs it is not just customers and orders, there are exceptions and weird cases, and they tell me that does not fit the model.

How it hits my status and my life: everyone acts like this is simple modeling, so I quietly wonder what is wrong with me that I cannot do it, and I am scared to push back on the devs because they might decide I am non-technical and stop listening. How I got here: my expertise accreted 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 that is exactly the skill I do not have. What it takes to get out: a modeling surface that starts from the domain concepts and the process rather than from tables, and an agent I can talk to that turns my five-minute human explanation into the typed structure, which is the talk-to-agents-and-they-build-it loop at the center of Scatter Model. Why most fail: the tools repel the non-schema-thinker 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. The cost of staying stuck is a system that encodes a simplified, wrong version of reality because I could not express the exceptions in their language. The cost to get out is trusting a tool that meets me in my own terms.

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 is no single source of truth for prompts or configs, it is 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 am pretty sure we are one quick fix in production away from never being able to reproduce our own behavior.

How it hits my status: I am supposed to be the one keeping this under control, and I have let a mess grow that I cannot fully untangle, and if a subtle prompt bug hits production leadership blames me for not having processes. How I got here: prompts and templates started as quick strings and were never promoted to first-class artifacts, so they propagated by copy-paste faster than anyone could centralize them, and the config sprawl followed the same path. What it takes to get out: a single source of truth where every template's variables are validated against the typed model, so a prompt cannot reference a field that does not exist and a template regenerates when the model changes, which is exactly the schema-driven Jinja layer Scatter Model owns. Why most fail: the sprawl is invisible until it breaks silently, and silent breakage produces no failing test to force the fix. The cost of staying stuck is losing the mental model of my own system while being responsible for it, which is the specific terror of this role. The cost to get out is treating prompts and configs as typed artifacts rather than strings.

P5. The data engineer who became a human code generator

My job lately is define 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, and this is not data engineering, this is unpaid codegen. I have 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.

How it hits my status and my life: I keep seeing talks about elegant data architectures while I am wiring JSON fields for the tenth time, and I wonder if maybe I am just mediocre, or if I am not senior enough to be trusted with the interesting work so I get stuck with the boilerplate. How I got here: the ecosystem made the same conceptual model require a different syntactic restatement in every layer, so my expertise got spent on the restating rather than on the data problems, one service at a time, until restating was the job. What it takes to get out: an intermediate representation that generates the SQL, the ORM model, the Pydantic model, the JSON schema, and the serializers from one definition, which is the codegen-and-export core of Scatter Model and the exact relief the market read says developers adopt tools to get. Why most stay stuck: 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 cost of staying stuck is a career spent on glue with the creeping doubt that this is all the work is. The cost to get out is letting one IR do the restating so the human does the interesting part.

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

I want to build a world. Characters, systems, economies, 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 is 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 am always choosing between playable and powerful.

How it hits my experience: 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. How I got here: the rich-model use cases (a game world, a simulation, a complex domain with many interacting entities) fall exactly in the gap the market read names, where ERD tools give a static diagram that is not the operational truth and low-code tools give a soft proprietary schema with no typed depth, so nobody serves the person who wants both playability and a hard model. What it takes to get out: ECS modeling made playable over a real typed IR, the Total Annihilation steely-gray-metal-planet canvas where you shape entities and components and agents help you tune them, which is the literal product vision of Scatter Model. This persona is the aesthetic heart of the brand and the bridge to Depths of the Void and the RPG-style persona profiles the ecosystem builds, because the same playable-world-modeling primitive serves both a business domain and a fictional universe. Why most settle: they accept the playable-or-powerful tradeoff because no tool has offered both. The cost of staying stuck is that world-modeling stays tedious and the creative flow stays broken. The cost to get out is adopting a tool that treats the model as a world you play rather than a table you fill.

5. The world model (run the PST framework)

The six personas share one suffering loop, and modeling it as a single problem-story is what turns the deck from a feature list into PST. Echolocate, locate the Problem, reconstruct the Story, 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 is invisible until it breaks. On another side is a tooling landscape 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 does not 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 exactly the agent-native modeling Scatter Model is. Read it the way an M&A firm reads a target and the leverage is obvious: the data model is the highest-leverage and most-neglected artifact in the system, the place where a small early error compounds into the largest downstream cost, which is precisely why owning it is worth a brand.

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. 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, the belief not I made a modeling mistake but I am a sloppy engineer, a mediocre data engineer, a non-technical fraud who cannot 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.

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 not like diligence but like exposing themselves to the old punishment. That is the uncomfortable part most of them run from, the recognition that the broken schema is not the market's fault or the framework's fault but the downstream of a fear they invested in. On the Hawkins scale used descriptively, shame, fear, and pride sit in the destructive band below the courage line, and the whole loop is fueled from there.

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, and the uncomfortable truth is that the data model is the product, not the overhead, the most load-bearing artifact in the system, and treating it as a first-class playable thing is the leverage rather than the tax. The second is responsibility, owning the reaction rather than the circumstance: the developer did not create the fractured tooling landscape, 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 is where the audience lives, with the playable, agent-tended, single-source-of-truth world shown as the reachable other side. That is the Echolocation architecture applied to the person whose data model is quietly breaking everything they build.

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 but in a different domain. Map it by cluster, by what each refuses, and by where the third door is.

Who else does this, and what they will not do. Four clusters plus one convergent threat. 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 is 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 are 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.

The convergent threat, named honestly. 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. This is the most important competitive fact in the deck, and pretending Scatter Model has the space to itself would be the kind of empty-idea claim the ecosystem forbids. The honest read is that the space is being approached but not occupied: each entrant owns one slice (Pydantic AI owns agents-on-top-of-existing-models, dbt owns analytics semantics), and none of them is building-and-maintaining-the-models-themselves visually and propagating them across infra and behavior. Scatter Model's differentiation has to be stated against Pydantic AI specifically, and it is clean: Pydantic AI builds type-safe agents on top of models you already have; Scatter Model builds and maintains the models themselves, visually and agent-natively, and projects them into every backend and template. Riding the Pydantic wave (being Pydantic-IR-centric) rather than fighting it is both the safer go-to-market and the more defensible position.

The third door. Alpha is the thing competitors know about and will not 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 will not connect them is structural. The schema tools are organized around code-first developer workflows and will not build a playable visual layer; the low-code tools are organized around non-developers and will not build a hard typed IR; the prompt tools are organized around AI-team workflows and will not reach into database schemas. Connecting the four requires a builder willing to do the unglamorous depth across all of them, which is exactly the weaponized-autism-to-Pydantic thesis the brand is named for.

Wardley evolution and the own-versus-rent call. ORMs, migrations, and schema validation are product-to-commodity, rent and harvest, never custom-build (Scatter Model uses Pydantic and the existing codegen tools as components rather than rebuilding them). The playable, agent-native, unified IR with the typed template layer is genesis-to-custom: novel, differentiating, load-bearing, and the thing competitors know about but will not connect, which is the textbook own-and-build capability where the alpha lives. The visual canvas is genesis and should be probed before heavy investment, because the market read warns it must be a front-end over a Git-native text IR rather than a replacement editor, 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.

Market size and demand signal. Triangulate, because there is no clean 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. 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. The category comps confirm the ceiling: Airtable at a reported $11B, Retool toward $6-8B, Hasura around $1B. Demand is proven by partial-fix adoption, the unified fix is unbuilt, and the agent-native wave is moving toward exactly the thing the brand is, which is the most favorable market shape a young brand in this category can read.

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

Scatter Model is concept-stage, so the build section is more provisional 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. 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. 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 the market read says are necessary so the single IR does not collapse to a lowest common denominator.

The hexagonal discipline. One IR core, surfaces many. 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. This is the same core-one-surfaces-many pattern the ecosystem runs on, and it is the mechanical defense against the Disconnection 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 cannot itself reproduce the model-the-data-N-times problem it exists to solve. There is a pleasing recursion here, that the data-modeling platform must itself be the cleanest example of single-source-of-truth modeling, and the hexagonal core is how it earns that.

The data models. Scatter Model is the meta case: it is the data-model platform, so its own data models are models-of-models, the schema for describing entities, components, relationships, constraints, projections, and templates. This is Pydantic-as-IR pointed at itself, which is exactly 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. Three feature factories, each a set of harnesses plus a gateway. The model-editor factory (the visual studio and its round-trip to the text IR). The derivation-and-update factory (the eight-step derivation plus the propose-review-with-blast-radius agent loop). The dynamic-template factory (the schema-driven Jinja layer and the codegen-and-export engine, which may split into two factories as scope grows). Each is the custom-modular-composable-harness pattern the Harness V2 build provides (referenced from, not copied).

The medallion tiers. Applied to model maturity rather than to 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 is the certified source of truth for a domain with a governed review-and-certification loop. The market read independently identifies this governed-stewardship loop as where the durable value sits, so the medallion tiering and the stewardship model are the same idea.

Where Track R feeds Track P. Track R has not started. 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). When the repo decks exist at, the value rubric ranks the combined wish-list and the specific capabilities slot in here.

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 is 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 is not blocked on Scatter Model the way it is blocked on WikiDesignCo's Wave-B metagraph; the productized brand is a force-multiplier that makes modeling faster and cheaper and sellable, not a substrate other brands cannot ship without. On the promise-dependency graph it is a high-leverage node whose promise is already partially kept by the internal discipline, which lowers its blocking-priority while keeping its leverage high.

Readiness is the honest 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 is genesis-stage, load-bearing, the alpha competitors will not connect, and high leverage across every brand's software angle. It is Next rather than Now because it is gated on the Harness V2 agentic stack being mature enough to run the propose-review loop reliably, and on the convergent-competitor landscape (Pydantic AI) being read before committing the differentiation. Routes Powell-VFA: it shapes many future decisions, score the discounted future.
• 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) per the market read's scoping caution.
• Watch (probe before heavy investment): the playable Three.js visual canvas. It is the aesthetic differentiator and the most novel surface, but the market read warns it must 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. Genesis, low-confidence, high-potential, the exact profile the rubric routes to a hands-on test.
• Leave (rent, never custom-build): ORMs, migrations, schema validation, the existing codegen tools. Commodity. Use Pydantic and the existing tools as components.

Run the seven-sins gate. Pride or look-ahead: the read scores the brand as concept-stage and the IR-unification as a bet, not as if it shipped. Envy or survivorship: the failure modes are in the deck (the lowest-common-denominator-IR risk, the playability-fights-Git risk, the convergent Pydantic AI threat), not just the upside. Gluttony or overfitting: the enthusiasm is capped to the proven internal discipline, not inflated by the feature surface. Sloth or transaction-cost: the build friction (the per-backend projection complexity, the agent-loop reliability) is named as the gate. 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. Lust or capacity delusion: Scatter Model is one foundational build with a narrow initial wedge, not an attempt to own every template surface at once. Greed or fat-tail: the tail risk is Pydantic AI or a low-code incumbent extending into the unified-IR space first, which is exactly why the differentiation must be read and committed deliberately, routing VFA rather than a rule-based adopt. The dependency to flag for the strategist: Scatter Model's leverage is high and its readiness is low, so it is a strong Next rather than a Now, and its sequencing should follow the harness maturing rather than lead it.