Scatter Model

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)

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.

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.

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.

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.

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

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

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'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 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 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.

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.

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.

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

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.

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.

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

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

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

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

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 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).

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

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

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

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

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

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

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

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.

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.

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.

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

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

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.

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.

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. 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. 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 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 that keep the single IR from collapsing to a lowest common denominator.

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.

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.

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.

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. 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, the value rubric that sets each brand's priority 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'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.

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.

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.