A client says what outcome they need. The system selects proven open-source capabilities from a curated shelf, composes them on a host that owns identity, data, theme and shell, verifies the whole workflow, and generates only the product-specific remainder. The model interprets and glues. Deterministic machinery owns everything that must be true.
Actionist is not Lovable with a bigger repository corpus. It is an operating system for assembling software, with four things that get more valuable with every build.
Industries, workflows, recurring solution atoms and product archetypes. 17 industries have been mapped; they compress to roughly ten B2B skeletons. You do not build seventeen stacks.
Reusable systems, what each actually provides, where its seams are, and the correct reuse shape for it. 3,010 sources discovered; the graph is what turns discovery into something a planner can use.
Standardises data, identity, connectors, UI and runtime at explicit seams, so a donor application can be absorbed whole and still behave as one product with one login and one theme.
Which compositions delivered which client outcome at what cost, fed back to the shelf. This is the asset a generator structurally cannot have: its thousandth app starts from the same blank context as its first.
Identities, dependency graphs, schema validation, namespace conflicts, declared ports, tenant requirements, build and test execution, release manifests. If it must be true, a machine checks it.
Interpreting ambiguous demand, understanding unfamiliar source architecture, proposing reuse shapes, mapping semantics, writing bounded transforms and glue, comparing trade-offs. Cheap models are an economic hypothesis to test once constraints make the problem small, not the architecture.
Product equivalence, reuse-shape calls, data-migration authority, irreversible surgery, admission and release. Five named decisions. Everything else is delegable.
A four-lane GitHub sweep, run to try to kill the thesis, returned 389 unique repositories, 181 of them permissively licensed. The finding is not any single repo. It is the shape of the result.
prompt-to-app, no-code, CRUD and dashboard generators
registries, boilerplates, design tokens, multi-tenant starters
AST codemods, sandboxes, schema introspection, wildcard-subdomain deploy
LLM emits structured UI, framework renders from a registry
repositories appear in more than one lane. Not few. Zero, across 389. The app builders do not have a supply shelf. The supply shelves have no planner. The extraction tooling has never met the host. The generative-UI libraries render from a registry nobody is curating. The composition is unoccupied, and this is the strongest evidence in the programme that the bet is real, because it came from failing to find a counterexample.
Each of these is an architectural property of generation-first builders, not a missing feature. Each maps to a part of the machine below.
No domain owns another domain's truth. A product spec does not choose a database. A repository does not define requirements. A model does not grant authority or invent compatibility. Qualification evidence does not mutate a semantic interface. The contracts between domains are the framework; models operate inside them.
outcomes, industry ontology, product specification
D01–D03discovery, capability mining, reuse-shape, extraction, thin contracts, registry
D04–D09data, identity, connectors, UI, archetypes, planning
D10–D15host/isolation, verification and promotion
D16–D17release, operations, economics, feedback
D18–D18| ID | Domain | Canonical output |
|---|---|---|
| D01 | Outcome and demand | OutcomeSpec |
| D02 | Industry / domain ontology | DomainPack |
| D03 | Product specification | ProductSpec |
| D04 | Source intelligence | SourceCandidate |
| D05 | Capability mining | CapabilityMap |
| D06 | Reuse shape and ownership | ReuseDecision |
| D07 | Extraction and adaptation | PackagedAsset |
| D08 | Thin capability contract | CapabilityContract |
| D09 | Registry and resolution | RegistryRecord |
| D10 | Data plane | DataResourceContract |
| D11 | Identity and authority | AuthorityContract |
| D12 | Connectors | ConnectorContract |
| D13 | UI and taste | DesignSystemContract |
| D14 | Archetypes and shells | ArchetypeTemplate |
| D15 | Composition planner | AssemblyPlan |
| D16 | Runtime and host | HostContract |
| D17 | Verification and qualification | QualificationDossier |
| D18 | Release and learning | ReleaseManifest |
Hover or tap a part. Purple edges are what it depends on; mint edges are what depends on it. Dashed nodes are open; solid nodes are partially built. Every part page, thesis and open question exists on the system map.
Begin with everything Actionist already knows, enrich it with bounded public business context, then ask only the questions needed to identify valuable workflows.
Actionist account profile, Client URLs, Conversation, Existing tools → ClientContext, DiscoveryGapList, CandidateOutcomes
vs a generator: Lovable starts every project from an empty prompt box, so the client must already know what to ask for. Starting from known account context and public business signals means the first question is about a painful workflow, not a feature wishlist.
Translate business conversation into a small, testable ProductSpec before selecting repositories or UI.
ClientContext, Industry model, Conversation → OutcomeSpec, ProductSpec, AcceptanceFixtures
vs a generator: A prompt is not a specification, so there is nothing to test the generated app against and nothing to say when it is done. A testable ProductSpec with acceptance fixtures turns "does this look right" into a check a machine can fail.
Hand-curate the first high-value software capabilities—Notion-like notes, Airtable-like data, calendar, CRM, support, files, approvals—before trying to automate the whole internet.
ProductSpec demand, GitHub corpus, Local estate, Platform dossiers → CuratedCapability, CapabilityMap, ReuseDecision
vs a generator: Their quality ceiling is whatever the model writes in one context; a curated shelf inherits the ceiling of mature products that thousands of engineer-hours already hardened. Lovable cannot adopt a shelf without giving up the generality that is their entire pitch.
Automate source understanding, boundary extraction and adaptation evidence while keeping semantic reuse-shape decisions explicit and reviewable.
Repository, Target host contract, Desired capability → PackagedAsset, CapabilityContract, AdaptationRecipe, QualificationDossier
vs a generator: Generation-first builders have no way to absorb existing software: their only import path is a one-way git export, and they cannot start from an existing codebase at all. The foundry is the machine that converts the open-source estate into supply, which is a capital asset rather than a per-build cost.
Maintain a continuously refreshed, visually browsable component corpus where people and agents can find structural necessities and contextual inspiration.
21st stores, New component feeds, Screenshots, Source metadata → ComponentRecord, PreviewSet, CategoryGraph, Selection
vs a generator: Generic visual convergence is the reported outcome when every surface is drawn from the same model prior. Choosing from a browsable corpus of real components makes the visual result a selection the client can see beforehand rather than a sample they have to react to afterwards.
Learn a client’s visual preferences through a minimal sequence of high-information comparisons, separate from choosing individual components.
Design stimuli, Client choices, Brand constraints → TasteProfile, PreferenceConfidence, DesignDNA
vs a generator: Lovable lets a user bring a design system and then enforces it, which assumes the client can author one. Learning taste from a short sequence of structured comparisons gets a defensible visual identity from a client who could not have written the brief.
Preserve the quality of each imported capability while translating its visual assumptions into one semantic Actionist/client token system.
TasteProfile, Donor styles, Component tokens, Brand assets → ThemeContract, TokenMap, ScopedThemeBridge, VisualReceipts
vs a generator: Lovable scans each generation for raw colour literals and auto-retries, so enforcement itself is table stakes. The unoccupied ground is making an off-token value a build error rather than a retry prompt, which is only possible when the token system is closed and the pieces are known in advance.
Reuse application-level workflow skeletons without forcing every product into one five-area dashboard.
ProductSpec, TasteProfile, Component selections, Capability surfaces → ArchetypeTemplate, NavigationPlan, PageTopology
vs a generator: Prompt-to-app rederives application structure on every run, which is why it holds up on dashboards and CRUD and falls apart on multi-step business logic. A tested archetype supplies the workflow skeleton as a known-good starting point, so the model is never asked to invent topology it cannot verify.
Standardize typed data capabilities and ownership—not one database implementation inside every block.
Product entities, Capability requirements, Existing client systems → DataResourceContract, SchemaOwnerMap, Adapters, ReadModels
vs a generator: This is where their architecture is most exposed: the browser talks near-directly to Postgres and the row-level-security policies protecting it are written by the model, with no dev/prod separation. When the platform owns schema, migrations and policies, that whole failure class is removed rather than mitigated.
Give every capability one Actionist identity, tenant, settings hierarchy and navigation surface while removing duplicate donor onboarding and account chrome.
Actionist session, Tenant, Capability host requirements → HostIdentity, SettingsRegistry, NavigationRegistry, AuthorityContext
vs a generator: A generator has no host contract, so identity and settings are re-invented per app and there is nowhere to stand when a client wants one login across several tools. Owning the host is also what makes absorbing a mature donor product possible at all, which is the move a pure generator has no equivalent for.
Reuse broad provider catalogues and OAuth/action mechanics while Actionist owns tenant-scoped connections, authority and side-effect receipts.
Provider definitions, Tenant authority, Secrets → ConnectorContract, Connection, ActionReceipt
vs a generator: Lovable reached roughly 100 connectors in six months by building them; the permissively licensed catalogues already carry far more, and Activepieces alone ships 113 OAuth2 integrations with refresh logic and credential encryption. Importing the catalogue while owning tenant-keyed connections and the action ledger converts their multi-year roadmap into an integration exercise.
Retrieve candidates, eliminate incompatible sets mechanically, then let AI choose among feasible plans and write only bounded glue.
ProductSpec, Capability shelf, Archetype, Host contracts, Taste profile → AssemblyPlan, CompatibilityProof, ClarifyingQuestions
vs a generator: When a model both chooses the architecture and writes it, an incompatibility surfaces as a runtime bug the client pays to fix. Eliminating incompatible sets mechanically before any code is written means the failure mode becomes an UNDERDETERMINED question asked up front instead of a repair loop discovered later.
Clients need to alter the assembled product through conversation and direct visual controls without dissolving the composition back into arbitrary generated code.
AssemblyPlan, Running preview, Client instructions → ChangePlan, UpdatedBindings, BoundedDiff, Version
vs a generator: This is the part that produces their single loudest complaint: free-form regeneration on every edit is what causes fix-one-break-another loops and the 60 to 150 credits users report losing to AI-introduced bugs. Persisting typed edit intent against semantic anchors means an edit survives an upgrade or refuses out loud, and no version history is needed to undo damage that was never done.
Run heterogeneous capabilities in explicit profiles, verify the complete workflow, and release an exact recoverable composition.
AssemblyPlan, Packaged assets, Host bindings, Acceptance fixtures → QualificationDossier, ReleaseManifest, Deployment, RollbackPlan
vs a generator: Generation-first builders ship no tests and treat a working preview as proof, while their version history rolls back code without rolling back the database. Verifying the whole workflow and releasing an exact recoverable composition is the difference between a demo and something a business can depend on.
Every new component, repository, conversion and production outcome should improve the shelf, taxonomy, recipes and future recommendations.
New source feeds, Conversion receipts, Build metrics, Client outcomes, Incidents → Updated rankings, New recipes, Deprecations, Research priorities
vs a generator: Their thousandth app is generated by the same model against the same blank context as their first, so nothing accumulates except model upgrades everyone else also receives. Attaching outcome, adaptation-cost and incident evidence to stable reusable units makes every build rank the shelf for the next one — the advantage a pure generator cannot copy, because it keeps no unit for the learning to attach to.
The original monolithic Block Contract was too large; it fused what a thing does with how it is proven and how it is shipped. It became seven thin, linked records. The original code stays as intact as its reuse shape permits. Actionist-specific identity, settings, navigation and data come from host contracts and adapters, never from forking the donor.
Default is absorb-and-own. Running a donor as an intact service behind an iframe is debt that needs written justification, not a shortcut.
The decision unit is the tuple (source repository, capability, target context, host contract, reuse shape). Each axis advances independently, so "the source is reusable" and "it is proven in a named host" can never be confused again.
The composer returns one of FEASIBLE, INFEASIBLE, UNDERDETERMINED. Only these five decisions are reserved for a human:
This is not theory. It was worked out by assimilating a 70-module knowledge workspace into a host shell and recording every commit that had to exist. The contract that fell out is small.
// everything the host injects — nothing is stripped from the donor interface HostContext { identity: SignedIdentity; // fails closed: client mismatch, expired, missing workspace, empty capabilities database: DataAdapter; // host-owned authority, namespaced per block tokens: Record<string,string>; // colours, fonts, request context } mount(div, ctx: HostContext, donorApp) // the complete donor app, providers and router included // data authority: one owner per table and migration, never two { postgresSchema: "knowledge", redisNamespace: "knowledge", blobs: "knowledge" }
Shell and routes, one signed identity, the token map, the data plane. Blocks bring none of these. That is why donor login screens and marketing chrome come out.
Each nav item is a block. Each block gets a route, a schema namespace and the same identity. They sit side by side and never touch. Ten donors have run this way before.
A CRM row opening its documents goes as an intent to the host bus, which routes it to the other block's mount. Direct coupling is how you end up with four incompatible bridges.
A donor single-page app assumes it owns the page. Assimilation is removing that assumption five times. A manifest schema is bookkeeping; these are the actual problems.
The donor assumes it owns /. Mounted under a host prefix, every lazy chunk 404s.
Post-process the donor's built output: rewrite the public path to a host-set global, re-resolve chunk URLs. Never patch donor source — a source patch is owed upstream forever; an artifact rewrite survives a version bump.
The donor fetches /api and /graphql at its own origin.
A narrow request bridge wraps fetch, rewrites root-relative API calls to the host backend, attaches host request context, forces credentials. Everything else passes through untouched.
A web worker has its own global scope. Patching window.fetch does nothing there.
Inject a prelude into the worker bundle and rewrite its base URL directly. Any donor with worker-based sync or search will appear to work and silently fail its realtime path. Nobody predicts this one.
Two routers, one URL bar.
The manifest declares the split: host owns the global rail and the route, donor owns contextual navigation beneath it. Base path is configurable, defaulting to the capability's name.
A heavy donor bundle behind a host route paints late.
Prewarm: fetch the donor's assets without executing the donor app, so the cost is paid before the user navigates.
Seventeen chrome guards were written from what people noticed while using the workspace. Nobody had rendered the error path embedded — and the error path has its own marketing nav, download button and sign-in fallback. It was found by clicking, after 44 commits. Now it is a mechanical step: grep the donor for chrome signatures, then render every terminal state (error, auth fallback, empty, offline) embedded, with screenshots proving zero donor chrome.
Industries differ in entities, vocabulary, authority and obligations. Their products mostly share skeletons: case and workflow management, client portals, CRM, finance operations, scheduling, inventory, support, field operations, learning and content. The counter-intuitive supply finding: generic dashboards and admin starters are abundant, so a dashboard is an easy demo and a weak test. Case-workflow and portal systems appear constantly in demand and have thin, clean supply. That is where the thesis is actually tested.
Each slot names a capability a business needs (workspace identity, roles, audit, files, workflow engine, connector catalogue, and so on), the layer it lives in, and the stage of a company's life it serves. 68 of the 80 slots already have ranked source candidates, 248 candidate edges in total. Recipes (Digital Business OS, SaaS OS, Ecommerce OS, Marketing Agency OS, Course Creator OS) compose slots into a whole operating system for a business type.
| govern | operate | acquire | activate | sell | deliver | support | retain | measure | total | |
|---|---|---|---|---|---|---|---|---|---|---|
| platform | 4 | 1 | 5 | |||||||
| engine | 3 | 1 | 3 | 3 | 10 | |||||
| capability | 1 | 2 | 1 | 2 | 6 | 3 | 15 | |||
| product | 4 | 3 | 8 | 12 | 5 | 6 | 38 | |||
| surface | 6 | 1 | 2 | 2 | 1 | 12 | ||||
| total | 5 | 10 | 9 | 2 | 13 | 23 | 5 | 9 | 4 | 80 |
Every number on this page is re-derived from the estate's own machine-readable records at build time. A cynical reader should start here.
The critical path is not "qualify the workspace block". It is: give the data-grid block the host it needs, put one tenant-scoped dashboard on top using the demo loop that already works, and qualify the block against that host as the first admitted block. That single slice retires more risk than the whole shelf.
jti with subject, tenant, workspace, audience, client, capabilities, expiry, revocation. Issue, exchange, read-back, revoke. Six negatives fail closed.Action Model is the use case that justifies the build. The asset is the machine. Every stage of the foundry that is tooled is a stage an agent can run unattended; every admitted block is a capability any future product gets for free; every client engagement adds blocks, recipes and production evidence back to the shelf.
Agents sweep the open-source world against the demand graph. 3,010 sources are already shelved; millions are indexable.
The foundry reads architecture, picks a reuse shape, crosses the five seams, and emits the seven records. Human judgement only at the five named decisions.
Every block is proven in a named host with negatives, or it is not a block. Admission stays separate from source status, forever.
A client outcome becomes a ProductSpec; the planner eliminates incompatible sets and picks a feasible plan; glue is bounded and verified.
Outcome, adaptation cost and incidents flow back to the shelf, so the next composition starts from evidence instead of a blank prompt.
The practical consequence: any business's stack becomes assemblable from qualified parts, industry by industry, on a shelf that gets sharper with use. A generator's moat is its model. This system's moat is everything the model is not allowed to decide.