Actionist decision timeline

Updated: 2026-08-28

This is the chronological decision record for how the Actionist research is becoming an architecture and pilot. It records current interpretation; original evidence remains in research/.

2026-08-26 — breadth research established the problem

• Research mapped 17 industries, recurring workflow atoms, repository supply, builder competitors and local SISO assets.
• The 17,000-slot matrix was corrected: broad observations did not equal 1,700 complete, reusable industry-repository pairs.
• The working thesis shifted from “find many repositories” to “understand capabilities, choose a reuse shape and standardize only the seams.”

2026-08-27 — Sprint 1 harvested independent evidence

• Five Opus lanes produced evidence for demand, capability supply, experience, host foundations, runtime and learning.
• Demand across 17 industries compressed into reusable horizontal capabilities plus industry-specific entities, authority and workflows.
• The universal foundation emerged: identity, organizations, navigation, settings, notifications, files, search, audit, tasks, forms, scheduling, connectors, reporting and portals.
• The industry layer remained separate: it supplies vocabulary, state machines, permissions, integrations and client-specific deltas rather than a new technical stack per industry.

2026-08-27 — Sprint 2 synthesized the framework

• A repository became a source container, not the reusable unit.
• The old monolithic Block Contract became seven linked records: capability, packaging, host, binding, qualification, registry and release.
• The deterministic composer gained explicit FEASIBLE, INFEASIBLE and UNDERDETERMINED outcomes.
• Five runtime profiles were defined: package in host, microfrontend, sidecar service, worker and scheduled job.
• The data rule became: share infrastructure where efficient, but keep one authoritative owner per table, schema migration, file namespace and event stream.

2026-08-28 — stacking model clarified

• “Ten applications together” means one composed Actionist product with roughly ten capabilities, not ten complete SaaS stacks by default.
• Compatible capabilities share the host process; browser-only surfaces can ship as static microfrontends; jobs share worker and scheduler infrastructure.
• Intact donor applications receive separate processes only when their architecture or migration ownership requires one.
• Capabilities can share one managed Postgres cluster and connection pool while retaining separate schemas, roles and migration ownership.
• Cross-owner product views use typed APIs and event-fed Actionist read models rather than arbitrary cross-schema mutation.
• Runtime density is still unmeasured. Sprint 3 must record process count, idle/active memory, CPU, connection budgets, storage growth and total composition cost.

2026-08-28 — pilot strategy and vertical shortlist

The pilot does not lock Actionist to one industry. It is a proving ground for the horizontal platform and the source-to-module foundry.

Operator priority group

1. SaaS companies — broad reusable demand across CRM, onboarding, support, billing, product operations and reporting.
2. Ecommerce — strong source and template supply; high-value order, inventory, support, cart-recovery and Stripe/payment workflows.
3. Marketing and social agencies — strategically aligned with selling to agencies; strong client approval, scheduling, asset and reporting workflows.

Strong adjacent candidate

• Course creators — commercially interesting due to an identifiable automation opportunity and a wider creator market; combines payments, onboarding, content delivery, community, scheduling and follow-up.

Retained later candidates

• Property management remains a strong systems stress test because it combines internal operations, external identity, work orders, vendors, documents and payments.
• Law firms remain a deeper authority/document/deadline stress test but are harder to reach as the first commercial wedge.

No single pilot industry is locked yet. Sprint 3 should compare the priority group using accessible client evidence, market value, reusable source supply, measurable outcome and ability to exercise heterogeneous reuse shapes.

What “three real shapes” means

The three shapes are technical reuse modes inside one pilot workflow, not three industries:

1. Intact service — retain a mature donor application and bind it to Actionist identity, navigation, settings and data/read-model seams.
2. Transplanted or embedded capability — absorb a bounded product surface into the Actionist host so it shares the host runtime and user experience.
3. Engine plus Actionist-owned surface — borrow a mature computational/workflow core while Actionist owns the client-facing UI, entities and product behavior.

The first pilot should contain all three so the framework is tested against real architectural variation. Generic SaaS dashboard infrastructure remains a shared control/foundation, not the strategic pilot outcome.

Current next gate

Before implementation, produce a comparative pilot decision packet for SaaS, ecommerce and marketing/social agencies, with course creators retained as the adjacent candidate. For each candidate:

• name one bounded workflow and measurable economic outcome;
• identify the horizontal capabilities reused everywhere;
• nominate concrete sources for the three reuse shapes;
• draft the seven linked module records;
• hand-run the deterministic composer;
• estimate normalization surgery and runtime density;
• select, redesign or stop based on evidence rather than enthusiasm alone.