Install on Windows
Open PowerShell and paste one of the snippets below. The installer asks a single question — Ready to go (pre-built images and guided portal surfaces) or Customizable (full source clone, Build Studio and a local IDE share the same workspace) — and handles everything else: Docker Desktop, WSL2, hardware detection, AI model selection, credential generation, and auto-start. Use Customizable for serious source edits while Build Studio hardening continues.
Recommended: with the GitHub CLI
gh api repos/OpenDigitalProductFactory/opendigitalproductfactory/contents/install-dpf.ps1 -H "Accept: application/vnd.github.raw" > install-dpf.ps1
powershell -ExecutionPolicy Bypass -File install-dpf.ps1Without the GitHub CLI
iwr https://raw.githubusercontent.com/OpenDigitalProductFactory/opendigitalproductfactory/main/install-dpf.ps1 -OutFile install-dpf.ps1
powershell -ExecutionPolicy Bypass -File install-dpf.ps1.admin-credentials in your install directory. After installation: dpf-start to start, dpf-stop to stop.
main with green CI. Real-hardware verification reports are what graduate them from Early Access to GA — see the Quick Start table and the dedicated install runbooks under docs/install/.
Recommended hardware
The platform supports a broad range of hardware, but the experience changes depending on whether you want simple evaluation, day-to-day local AI, or sandbox-heavy self-building. The installer detects your CPU, RAM, and GPU and picks an appropriate local model automatically — you do not need to size anything by hand.
| Tier | CPU | RAM | Storage | GPU | Best for |
|---|---|---|---|---|---|
| Minimum viable | Modern 4 cores | 16 GB | 50–100 GB SSD | None required | Evaluation, administration, and external-provider-first usage |
| Recommended | 8+ cores | 32 GB | 100–200 GB NVMe SSD | Optional, 8–12 GB VRAM | Small-team use, local-first AI, moderate sandbox iteration |
| Self-building | 12+ cores | 64 GB+ | 200+ GB NVMe SSD | 16 GB+ VRAM | Frequent sandbox launches, heavier local models, tighter iteration |
For the full deployment picture — container topology, the local-AI model selection table, and the monitoring stack — see architecture/platform-overview.
What this page is
You can explore the platform's documentation here without installing anything. The full user guide, architecture references, and standards documents are kept inside the repository so they stay in lock-step with the running code; this page is a curated entry point that links into them.
User Guide
Day-to-day operating guidance for everyone who uses the platform — market archetypes, getting started, AI coworkers, Build Studio, Edge Nodes, wiki, managed documents, compliance, finance, HR, customers, and more.
Architecture & Standards
The Trusted AI Kernel (TAK), Global AI Agent Identification and Governance (GAID), the white paper, and the platform's own conformance assessment.
Specifications & Plans
Long-form design specs that record how each capability was built. Useful as historical context, not as onboarding material.
Why the platform exists
Enterprise software for portfolio management, enterprise architecture, backlog tracking, and lifecycle governance has traditionally been locked behind expensive platforms that require dedicated teams to operate. Capable AI agents change that economics: the know-how of those professionals can be commoditized into a limitless workforce, as long as governance keeps humans in the loop.
Every screen has a context-aware AI coworker. Every action they propose flows through human-in-the-loop governance. Every decision is audit-logged.
A built-in local AI engine ships with the platform, so no data leaves your environment unless you opt into an external provider.
Build Studio is the governed self-development surface: it drafts, records evidence, and prepares changes through review gates. Complex source work can still use VS Code in customizable installs while Build Studio continues hardening.
Each install is a node. You can share what you build with the community and pull in what others have built. Sharing is always opt-in.
What you can do with it
A condensed view of the capability surface. Each capability has its own section in the user guide. Capabilities are aligned to the IT4IT v3.0.1 value streams (Evaluate, Explore, Integrate, Deploy, Release, Operate) so governance and lifecycle stay in lock-step with how the rest of your IT estate is modelled.
| Capability | What it is for |
|---|---|
| Portfolio Management | Organize digital products into portfolios with health metrics, investment tracking, and lifecycle management. |
| HR & Workforce | Manage employees, roles, reviews, timesheets, and organizational structure. The same role hierarchy (HR-000 through HR-500) drives platform access. |
| Customer Relationships | Track customer accounts, sales pipeline from lead to order, and engagement history. |
| Compliance & Regulatory | Onboard regulations and standards, map controls to obligations, collect evidence, track posture, and manage licensing readiness. |
| Financial Management | Invoices, suppliers and bills, purchase orders, banking and reconciliation, AI-spend visibility. |
| Enterprise Architecture | Model the application, technology, and business layers with ArchiMate notation; graph-backed via Neo4j. |
| Archetype-led portal | Public-facing storefront or service portal plus internal vocabulary for the selected business type. Driven by an archetype that seeds sections, flows, item templates, finance assumptions, marketing posture, and worker-home direction. |
| Build Studio | A guided five-phase pipeline (ideate, plan, build, review, ship) with AI coworkers, sandbox execution, code intelligence, impact reports, and promotion or PR handoff where configured. Active hardening is underway for oversized-build decomposition and safer portal upgrades. |
| Operations & Backlog | Manage delivery work with epics, items, priorities, and status tracking. Coworkers create, triage, size, and link items through governed MCP tools. |
| AI Workforce | Provider configuration, dynamic model discovery, capability-tier routing, operations map, capacity continuity, capability-needs review, agent registry, and per-agent grants. |
| Autonomy & WWMD | Decision Perspective Gate for ambiguity: wiki retrieval, principle-vector scoring, risk and confidence guardrails, outcome ledger, and escalation or deferral when the platform should learn before acting. |
| Wiki & Managed Documents | Governed platform knowledge, founder-kernel principles, source citations, linting, maintained documents, versions, references, and publication state. |
| Edge Node | Host-resident trust and discovery component with enrollment, operator approval, heartbeat freshness, local collectors, and multi-host/air-gapped runbooks. |
| Identity & Federation | LDAP, Active Directory, and Microsoft Entra federation for sign-in and directory bootstrap; the platform remains the source of truth for roles, route bundles, and coworker associations. |
| Common Skills Library | A registry of reusable, role-bound AI skills (.skill.md files) declaring tools, triggers, risk band, and which coworkers can invoke them. |
| Agent Interoperability | Internal coworker runtime structured around an A2A-aligned task envelope; MCP (Model Context Protocol) for tool and context interoperability. |
| Observability & Evidence | Prometheus-based discovery and metrics, an append-only authorization decision log, and chain-of-custody traces linking principal, agent, tool call, approval, and outcome. |
| Hive Mind | Opt-in cross-install contribution: features built locally can be reviewed, parameterized, and shared so the next install gets them out of the box. |
Themes that shape the experience
Beyond a list of features, four themes shape what working on the platform feels like day-to-day. Each is a deliberate design stance, not just a checkbox.
A bundled local AI (Docker Model Runner) starts before the platform does, so an onboarding-coo coworker can introduce itself, explain provider options in plain language, and walk you through identity, branding, and finance setup using the real settings pages — not a throwaway wizard. Honest about its own limitations (it’s running on a local 8B model), interruptible, and resumable.
Twelve market categories and 45 leaf archetype templates ship with the platform. Choosing one bootstraps the customer portal, vocabulary, booking and form rules, finance assumptions, marketing posture, and internal worker-home direction. The archetype is the single source of truth for industry; downstream surfaces read from it rather than from a separately editable string.
Skills are declared as .skill.md files with frontmatter for required tools, triggers, risk band, and which coworkers can invoke them. They are seeded idempotently and gated by the same grant model as every other tool call — default-deny, audit-logged.
Responses are scored. Conventions are accumulated. Stable conventions graduate into codified tools. Build features go through a Reusability Check at design time so domain-specific instances get parameterized for the hive mind, not hard-coded.
Twelve market categories, 45 leaf archetypes
Archetypes are the bootstrap mechanism that turns a fresh install into a working business setup. Each one carries storefront design, vocabulary, role emphasis, process defaults, finance assumptions, and marketing posture. The next design wave extends the same archetype into internal workspace homes: dispatch boards for trades, appointment-readiness boards for clinics, merchandising boards for retail, and equivalent daily boards for other categories.
Healthcare & Wellness
Clinics, practitioners, wellness providers; appointment-centric flows.
Beauty & Personal Care
Salons, spas, stylists; service menus, booking, deposits.
Trades & Maintenance
Plumbing, electrical, HVAC, handywork; quote-and-job workflows.
Professional Services
Consultancies, advisors, agencies; engagements, retainers, deliverables.
Software Platform
Software products and SaaS; subscription, releases, support.
Education & Training
Schools, training providers, coaches; cohorts, enrollment, certification.
Pet Services
Vets, groomers, trainers, boarding; pet records and visit history.
Food & Hospitality
Restaurants, caterers, hosts; menus, reservations, events.
Retail & Goods
Retailers and product sellers; inventory, orders, fulfillment.
Fitness & Recreation
Gyms, studios, leagues; memberships, classes, attendance.
Nonprofit & Community
Charities, associations, community groups; donations, programs, volunteers.
HOA & Property Management
Homeowners associations and property managers; residents, dues, violations.
Meet the coworker workforce
Coworkers are role-bound AI personas, each scoped to a value stream, each with its own grant set and skill library. They are the platform’s primary surface for getting work done — you talk to the coworker who owns the area you’re working in, and the platform routes you correctly based on the page, active archetype, and permissions in play.
onboarding-coo
Hosts first-run setup. Introduces the platform, explains AI providers, walks through identity, branding, and finance configuration.
coo
Ongoing operational partner once onboarding completes. Cross-functional: pulls from any value stream when the question doesn’t fit a single specialist.
portfolio-advisor
Digital products and portfolios — health, investment, lifecycle.
ea-architect
Enterprise architecture — ArchiMate views, capability maps, dependencies.
build-specialist
Drives Build Studio: design docs, sandbox builds, code intelligence, test-first decomposition, code review.
compliance-officer
Standards onboarding, licensing readiness, control mapping, evidence collection, posture tracking.
hr-specialist
Workforce, roles, reviews, timesheets, organizational structure.
customer-advisor
Customer accounts, sales pipeline, engagement history.
storefront-advisor
Storefront content, archetype-driven sections, vocabulary, design system.
inventory-specialist
Items, stock, fulfillment, orders.
marketing-specialist
Brand voice, content, campaigns — reads from the same archetype that seeded the storefront.
ops-coordinator
Operations and backlog: epics, items, priorities, status, scheduling.
platform-engineer
Platform health: providers, model routing, agent registry, infrastructure observability.
docs-specialist
Documentation upkeep — architecture, user guide, in-product help.
admin-assistant
Cross-cutting administrative work: scheduling, reminders, filing, follow-ups.
Build Studio: the five-phase pipeline
Build Studio is how the platform extends itself. A user (or a coworker on a user’s behalf) proposes a feature, and the request flows through five governed phases. Each phase has its own gate — nothing advances until the previous gate’s artifacts are present and acceptable. It is actively being hardened, so treat it as the governed evidence and development surface, not a promise that every complex source change is already fully autonomous.
| Phase | What happens | Gate / artifacts |
|---|---|---|
| 1. Ideate | Intake and creative discovery. The onboarding-coo or build-specialist drafts a feature brief, runs the Reusability Check, and creates a backlog item with a constrained goal. | Feature brief, backlog item, reusability analysis stored on the design doc. |
| 2. Plan | Architecture review and test-first task decomposition. Build-specialist drafts a design document covering problem statement, data model, reuse plan, and acceptance criteria. | Design document approved; severity-driven review (critical fails, important and minor pass). |
| 3. Build | Test-first implementation in a sandbox container. Each task: write failing test → implement → code review → pass → next task. Commit SHAs and task results captured. | All tasks complete; sandbox tests green; commits recorded. |
| 4. Review | Acceptance verification. Full test suite, typecheck, manual acceptance checks, UX verification, code-impact review. | Verification output, impact report, acceptance criteria checked, manual test steps documented. |
| 5. Ship | Delivery. Promotion evidence is prepared; where configured, a pull request opens against main with required CI checks and DCO sign-off. Hive contribution mode (fork_only, selective, or contribute_all) decides whether the change is also offered upstream. |
PR/promotion record, deployment or handoff confirmation, optional hive contribution PR. |
Build Studio captures phase-by-phase evidence so the path from idea to ship is fully reconstructable — the same evidence trail the compliance module uses when it asks “what changed and who authorized it?”
The Dale HVAC dogfood run exposed a real cliff: a feature can be directionally correct but too large for one Build Studio plan. The new design-time decomposition work keeps one parent design contract and creates smaller child builds before plan review oscillates.
Multiple builds run in parallel up to a configured sandbox-slot limit; further work queues rather than oversubscribing the host. The queue and concurrency surface is part of the Build Studio layout, not a hidden setting.
Heartbeat tickers wrap slow LLM awaits; the orchestrator detects stalled-at-pending and contradictory pipeline states and surfaces a Reset Build action so an operator can recover without writing SQL or restarting a container.
Each build records token, tool, and cache spend per phase in BuildPhaseRun + ToolExecution. The Build Studio card breaks down where a build’s budget went; the same numbers flow into the finance module’s actual AI spend.
The Build Studio surface is workflow-primary with an anchored inspector, a history strip that folds duplicate stall events, and per-task drawers — designed for an operator running multiple concurrent builds, not a single demo path.
AI workforce: local-first, with optional cloud
The AI workforce ships ready-to-run on your own hardware and grows as you connect external providers. Routing decisions are dynamic and capability-tier driven — never hard-pinned to a specific model in seed data — so the platform can pick the right LLM for each task type and sensitivity level without manual configuration.
Docker Model Runner is built into Docker Desktop 4.40+ — the platform pulls an appropriately-sized local model on first run, with real-time progress, and activates it before you see a setup screen.
External providers are an upgrade, not a prerequisite. Sensitivity clearance per provider decides which traffic each one is allowed to see; local stays the default for restricted data.
When supported, the platform queries each provider’s /v1/models endpoint at activation time rather than relying on a hard-coded list, so newly released models become available without a platform update.
Routing chooses by capability tier (reasoning, coding, summarization, etc.) and task type, intersected with sensitivity clearance and provider rate budgets. Champion/challenger A/B with promotion gates lets routing improve over time.
Every coworker has an explicit grant set. The TOOL_TO_GRANTS map intersects user capability with agent grants on every call — missing grants are logged with a rationale code, not silently bypassed.
Provider usage flows into the finance module as actual AP spend — per provider, per agent, per workflow, per Build Studio phase. Anthropic prompt-cache hit/miss telemetry and accurate per-model pricing make the numbers real, not estimates. Budget events fire at phase boundaries; rolling thread compaction and phase-boundary summarization keep token consumption bounded on long-running work.
Whenever a coworker hits an ambiguity or an open product question, the Decision Perspective Gate aggregates platform principles as weighted vectors and returns one of recommend, arbitrate, escalate, or defer with a confidence score and an audit record. Same gate is exposed as an MCP tool so external clients use it under the same rules.
A bundled speaches (faster-whisper) STT service is the default path for voice input where enabled. TTS profiles are optional enrichment for spoken decision rationales and read-back of profile output. Voice never changes approval, confidence, or audit rules, and real-person voice requires consent.
Saved operator views, reset controls, capacity continuity, and capability-needs review help operators see where AI work is active, blocked, underused, or asking for new platform support. Route topology overlays live provider activity, failover curves, quota pressure, and scheduled-window forecasts onto a single time-scrubbable map.
Autonomy grows through WWMD, not blind automation
DPF is deliberately walking toward more autonomous AI coworkers, but autonomy is earned through inspectable decisions. WWMD — the working shorthand for “What Would Mark Do?” — is the Decision Perspective Gate that turns the founder-kernel wiki into a repeatable answer path for ambiguous questions. The point is not to make a founder persona magic; the point is to make product judgment explicit enough that a coworker can explain why it recommends, arbitrates, escalates, or defers.
wiki_query searches founder-kernel and organization overlay pages. Vector search finds semantic matches; optional PPR re-ranks pages through the wiki link graph.
principle_decide compares options against tiered commandments, core principles, and contextual rules using signed dimension vectors.
Multiple vector analysis, one explainable answer
WWMD does not answer by vibe. It combines several kinds of signal so the response is balanced rather than overfit to one principle or one nearest-neighbor search result.
| Outcome | What it means for trust at scale |
|---|---|
| Recommend | The gate has enough signal to advise a path, but the caller still owns execution and approval. |
| Arbitrate | For low-risk decisions with very high confidence, the coworker may continue under its declared autonomy policy. |
| Escalate | The gate found risk, conflict, weak confidence, or policy boundaries that need a human resolver. |
| Defer | The wiki or decision profile lacks enough coverage. The unresolved question becomes learning material instead of a hidden guess. |
Why this matters: every unanswered or low-confidence WWMD question is a chance to improve the kernel. Over time, repeated human resolutions become reviewed wiki and perspective material, which lets coworkers handle more decisions safely without losing the audit trail. See the deeper architecture note: Autonomy, WWMD, and trusted coworker decisions.
The data layer and sandbox containers
The platform is a containerized stack with a small, deliberate set of stateful services. Knowing what lives where helps you reason about backups, sovereignty, and the boundary between safe iteration and production state.
| Service | Role |
|---|---|
| portal | The Next.js application surface for everything users touch — operations, portfolio, architecture, coworkers, storefront, governance. Only service published externally. |
| portal-init | One-shot startup container that waits for infrastructure, applies Prisma migrations, runs idempotent seeds (archetypes, skills, agents, role bundles), and exits. |
| postgres | System of record. Transactional platform data: organizations, products, portfolios, backlog, agents, grants, decisions, evidence. |
| neo4j | Graph storage for relationship-rich models — enterprise architecture, capability views, dependency chains, delegation chains. |
| qdrant | Vector database for semantic indexing, retrieval, and memory-style AI support. |
| inngest + redis | Durable execution engine for scheduled jobs, event-driven workflows, and retryable background tasks. Long-running coworker work surfaces through the coworker panel rather than blocking the UI. |
| Docker Model Runner | Local AI inference, built into Docker Desktop 4.40+. Models managed via docker model pull; GPU passthrough is automatic when supported hardware is present. |
| Sandbox containers | Disposable, on-demand containers used by Build Studio. New features get drafted, tested, and reviewed inside a sandbox before any change touches the running portal. Sandboxes are not part of the steady-state runtime — they spin up when work needs them and tear down when it ships. |
Identity, federation, and agent interoperability
The platform treats human and agent identity as one design surface. Humans sign in through your existing directory; agents carry their own durable identifiers and traceable claims; coworker-to-coworker work travels as a governed task, not as an implicit chat side-effect.
| Surface | What it provides |
|---|---|
| LDAP / Active Directory / Entra | Federation for sign-in and directory bootstrap. Upstream identities are linked to internal principal records via a principal-linking layer. Directory facts and legacy app compatibility flow through the upstream authority; platform roles, route bundles, and coworker associations stay authoritative inside the platform. |
| GAID identifiers | Every agent carries a stable identifier formatted as gaid:priv:<issuer>:<agent-id>. The Agent Identity Document (AIDoc) carries badging, assurance claims, and authorization classes. Contributions are obfuscated rather than anonymous — a stable pseudonym makes contributors distinguishable across the hive mind. |
| A2A-aligned task envelope | The internal coworker runtime is being refactored into an A2A-shaped, task-native architecture. Coworker-to-coworker handoffs are represented as governed tasks, outputs as task artifacts, clarifications and progress as task messages and status events. TAK runtime controls and GAID receipt semantics layer onto the same envelope, so future private or public A2A endpoint exposure is a projection rather than a rewrite. |
| Model Context Protocol (MCP) | Tool and context interoperability for the AI workforce. Platform capabilities, backlog operations, build operations, and hive contribution all expose MCP tools that any conformant client can call — under the same grant and approval gates that the in-product coworkers face. |
Observability and evidence
Governance is only worth the policy if you can see what happened. The platform ships with discovery, metrics, and an append-only audit ledger so every meaningful action by a human or an agent is reviewable end-to-end.
A discovery collector queries Prometheus targets, classifies scrape jobs (postgres, neo4j, qdrant, portal, sandbox, model runner, node exporter), and feeds the estate inventory used by enterprise architecture views.
Every allow/deny decision records actor type, action key, GAID context, rationale code, and timestamp. Tools are gated by a default-deny tool-to-grant map; unapproved calls do not silently succeed.
Tool executions are traced with W3C Trace Context, signed message envelopes, and links between principal, delegated authority, approval gate, and resulting state change — the substrate for compliance answers like “what did agent X do, and who authorized it?”
The compliance module attaches collected evidence to mapped controls. Build Studio captures phase-by-phase artifacts (design doc, verification output, acceptance check) so the path from idea to ship is reconstructable.
Every coworker call records token counts, prompt-cache hit/miss, model, and elapsed time. BuildPhaseRun and ToolExecution roll those up by phase and by tool; AgentBudgetEvent records budget pressure events and pre-dispatch rate-limit checks against the CLI pool.
Compliance, evidence, and audit
Compliance is treated as a first-class concern in the data model rather than a reporting layer bolted on top. Standards and regulations are first-class objects, controls map to obligations, evidence is collected against controls, and the audit ledger ties every governed action back to a principal, an authority, and an outcome.
| Surface | What it provides |
|---|---|
| Standards onboarding | Bring in regulations and standards as structured records (e.g., ISO/IEC 27001, SOC 2, HIPAA, PCI-DSS). Each standard’s clauses become obligations the platform can map to. |
| Control mapping | Map your operating controls to obligations across one or more standards. The same control can satisfy clauses in multiple standards without duplication. |
| Evidence collection | Attach evidence to controls — screenshots, exported reports, signed records. Build Studio phase artifacts (design doc, verification output, acceptance check) are addressable evidence by default. |
| Authorization decision log | Append-only record of every allow/deny decision with actor type, action key, GAID context, rationale code, and timestamp. The substrate for the auditor question “who authorized this, on what basis?” |
| Chain-of-custody traces | Tool executions are traced with W3C Trace Context and signed message envelopes (RFC 9421-aligned), linking principal, delegated authority, approval gate, and resulting state change. |
| Posture tracking | Standing posture view across the standards you have onboarded — which obligations are covered, which controls are stale, where evidence gaps exist. |
Because human and agent actions flow through the same authority resolution, evidence and audit cover the AI workforce on the same footing as the human workforce. An agent is just another principal whose decisions are logged.
Security and operational posture
Security choices follow from the sovereignty stance: the smallest viable network exposure, the smallest viable trust radius, and the smallest viable amount of data leaving your environment.
Only the portal is published externally (typically port 3000). Postgres, Neo4j, Qdrant, Redis, Inngest, and the model runner stay on the internal Docker network. Sandbox containers are launched on demand and torn down when they ship.
Install-time credentials are generated locally and saved to .admin-credentials in your install directory. External provider credentials live in the platform’s credentials store, not in environment files; no provider key is hard-coded or shipped in seed data.
The TOOL_TO_GRANTS map enforces default-deny for both in-product coworkers and external MCP clients. Missing grants are logged with rationale; nothing is silently bypassed. Proposal-mode tools break out for human approval unless an explicit autoApproveWhen predicate matches a pre-authorized flow.
Build Studio drafts, tests, and reviews changes inside an isolated sandbox container before any change touches the running portal. Production state is read-protected from the sandbox; the sandbox is reset on each build.
Every code change — whether opened by a human, a coworker, or the hive contribution flow — lands via a pull request with required CI checks and DCO sign-off. Force-push protection on main; the platform never bypasses signing or hooks.
A platform preamble is injected into every coworker’s system prompt and never appears in user input. Combined with default-deny tool gating, this defends against prompt-injection attempts that try to widen agent authority through conversation.
Hive Mind: how cross-install value travels
The platform is open-source and runs as a single-organization install — one company, one database, no multi-tenancy. Cross-company value moves through the Hive Mind: features built locally are reviewed, parameterized, and offered back so the next install gets them out of the box. Sharing is opt-in, contributors are obfuscated but distinguishable (stable pseudonym via GAID), and every contribution flows through a pull request with required CI checks and DCO sign-off.
| Contribution mode | What it does |
|---|---|
| fork_only | Build Studio ships the change to your install only. Nothing leaves your environment. The right setting for company-specific customizations. |
| selective | Each finished build is assessed for community value (the contribution-assessment uses the design-time Reusability Analysis as input). You decide per-build whether to contribute upstream. |
| contribute_all | Every successful build that passes the contribution gate is offered upstream automatically. The right setting for installs running ahead of the community on shared problems. |
Generic features become better business-model templates for everyone. The HOA example: a customer’s violation-logging feature gets reviewed in Build Studio; if broadly applicable, it is re-factored into the HOA archetype so future HOA installs adopt it on day one. This is what “the platform grows from within” means in practice — recursive self-improvement, where every platform improvement is also a sellable capability for the next operator.
The platform as a programmable surface (MCP)
The Model Context Protocol (MCP) lets external clients drive the platform with the same tools, the same grants, and the same approval gates that the in-product coworkers face. That means you can connect the platform to your existing AI tooling without giving anything a back-door — every external call is authorized, audited, and traceable, just like a button click.
Backlog operations, digital-product registration, build orchestration, evidence recording, taxonomy placement, hive contribution, and feedback all surface as MCP tools with declared requiredCapability, executionMode, and sideEffect fields.
A bearer token maps to a principal; the principal’s capabilities intersect with the calling agent’s grants on every tool call. Proposal-mode tools still break out for human approval; autoApproveWhen predicates allow pre-authorized flows for autonomous use.
Tool execution is logged under [tool-trace] with the request, response, principal, agent, decision, and rationale — the same trail in-product coworker calls produce.
Any MCP-conformant client (Claude Code, Claude Desktop, Codex CLI, custom orchestrators) can call into the platform once registered, without bespoke integration work. CLI vs Messages-API rate limits are tracked separately so a busy CLI session does not throttle the in-product coworkers.
Roles and access
The platform uses a two-tier role model so platform-wide governance is separated from product-specific operating structures. Tier 1 is six immutable roles aligned to IT4IT v3.0.1 value-stream authority. Tier 2 is per-product roles defined by the business model the product runs on (SaaS, Marketplace, IoT, etc.) — a user can hold different business-model roles on different products.
| Role | Name | Authority domain |
|---|---|---|
| HR-000 | CDIO / Executive Sponsor | Strategic direction, executive escalation, full platform access including user management and governance settings. |
| HR-100 | Portfolio Manager | Portfolio governance, investment allocation, approval of Portfolio Backlog Items (PBIs). |
| HR-200 | Digital Product Manager | Product lifecycle, backlog, delivery; the escalation target for blocked Product Backlog Items (PRODs). |
| HR-300 | Enterprise Architect | Architecture guardrails, technology standards, capability map ownership. |
| HR-400 | ITFM Director | Financial governance, cost allocation, AI-spend approval. |
| HR-500 | Operations Manager | SLA, incident response, operational continuity. |
Authorization is the intersection of two systems: the user’s platform-role capabilities (e.g., view_portfolio, manage_compliance, manage_users) and the calling agent’s declared grants. A coworker can only do what the user is allowed to do and the agent itself is granted to do. Superuser status (intended for initial setup, limited to one or two administrators) bypasses checks; everything else is default-deny and audited.
Privacy and sovereignty posture
“Runs on your hardware” is more than a deployment choice — it is a posture the rest of the platform is designed around. Local stays the default; cloud is an opt-in upgrade with explicit clearance; sharing is opt-in with a stable but obfuscated identity.
A bundled local model is activated on first run. Postgres, Neo4j, Qdrant, Inngest, and the model runner stay on your internal Docker network. Only the portal is published externally, and only on the port you choose.
External providers carry a sensitivity-clearance set (public, internal, confidential, restricted). Routing’s hard filter refuses to send a request to a provider whose clearance does not cover the data’s sensitivity. Local providers are cleared for everything.
Each install is one Organization — no multi-tenancy, ever. Cross-company value travels through the Hive Mind contribution flow, not through shared database rows. Company-specific customizations stay local; only what you explicitly contribute leaves.
Enterprise integrations (ADP, HRIS, ERP, banking) use your accounts, your credentials, and your vendor agreements. The platform connects to them on your behalf; it never enrolls itself as a partner of those vendors.
When you contribute back, GAID provides a durable identifier so distinct contributors are distinguishable across the hive mind — without exposing your organization’s real identity unless you choose to.
The platform is open source. The seeds, prompts, agent registry, route bundles, archetypes, and migration history are all in the repository. The customizable install is a full source clone — Build Studio and your local IDE share the same workspace.
Standards conformance profiles
TAK and GAID are not single-tier standards — they define a ladder so an implementation can declare what it actually supports and earn higher levels over time. The platform is the first proving ground; the conformance assessment in architecture/agent-standards-dpf-conformance shows the current mapping.
| Standard | Profiles | What rises with each level |
|---|---|---|
| TAK | TAK-Basic, TAK-Managed, TAK-Assured |
From baseline runtime mediation (auth, capability, tool gating, audit) up through delegation chains, immutable directives, evaluation discipline, and non-repudiation evidence sufficient for assurance review. |
| GAID | GAID-Private, GAID-Federated, GAID-Public |
From private namespace identifiers up through federated issuer trust, public AIDoc resolution, badging, and independently certified assurance claims. |
Both standards reference the broader policy context — ISO/IEC 42001:2023, NIST AI RMF 1.0, the NIST AI Agent Standards Initiative, the NCCoE concept paper on software-and-AI-agent identity and authorization, MCP, W3C Trace Context, RFC 9421 HTTP Message Signatures, and the OWASP GenAI Security Project — rather than reinventing them.
User guide — in-product help, also published here
These pages are bundled into the platform's in-app help and also live in the source tree. Start at the User Guide index and follow the section that matches your role.
| Section | Read |
|---|---|
| User Guide index | user-guide/ |
| Getting started | user-guide/getting-started |
| Market archetypes and coworkers | user-guide/market-archetypes |
| AI coworker | getting-started/ai-coworker |
| Roles & access | getting-started/roles-and-access |
| Development workspace | user-guide/development-workspace |
| AI workforce & providers | user-guide/ai-workforce |
| Build Studio | user-guide/build-studio |
| Compliance | user-guide/compliance |
| Licensing readiness | user-guide/compliance/licensing-readiness |
| Customers | user-guide/customers |
| Finance | user-guide/finance |
| HR | user-guide/hr |
| Operations | user-guide/operations |
| Platform & AI ops | user-guide/platform |
| Edge Nodes | user-guide/platform/edge-nodes |
| Portfolios | user-guide/portfolios |
| Products | user-guide/products |
| Storefront | user-guide/storefront |
| Wiki | user-guide/wiki |
| Managed documents | user-guide/workspace/documents |
| Workspace | user-guide/workspace |
| Admin | user-guide/admin |
Architecture & standards
The repository carries a draft standards family for trustworthy AI-agent operation and identity. The platform itself is the first implementation and conformance case. These documents are intended to be read together: TAK defines the runtime kernel and control model, GAID defines identity and governance claims, the white paper explains the policy context, and the conformance assessment shows how the platform maps to the proposed standards today.
| Document | Read on GitHub |
|---|---|
| Platform overview | architecture/platform-overview |
| Trusted AI Kernel (TAK) | architecture/trusted-ai-kernel |
| Global AI Agent Identification & Governance (GAID) | architecture/GAID |
| Trusted AI Agent Governance white paper | white paper (markdown) |
| Standards conformance assessment | agent-standards-dpf-conformance |
| A2A-aligned coworker runtime design | 2026-04-23-a2a-aligned-coworker-runtime-design |
| COO-led onboarding design | 2026-03-21-coo-led-onboarding-design |
| AI coworker development principles | ai-coworker-development-principles |
| Platform usability standards | platform-usability-standards |
Reference material that influenced the platform's modelling — including IT4IT mapping and the broader product-management taxonomy — lives under docs/Reference.
Specifications & plans
Long-form design specs that document how each capability was built. They are historical records rather than onboarding material, but they are useful if you want to understand the design rationale behind a particular feature, or if you are evaluating the platform's engineering discipline.
Specs index
docs/superpowers/specs — one design document per dated initiative.
Trusted AI Kernel context
For runtime governance and control flow, start with the TAK markdown alongside the specs.
Build Studio specs
Search the specs directory for "build-studio" to follow the evolution of the guided build pipeline.
Governance posture (at a glance)
“Humans hold authority. Agents hold capability. The kernel mediates.” That single sentence is the operating principle behind TAK and shapes everything below.
HITL tiers (0–3) decide when an agent can act on its own, when it must propose, and when escalation is mandatory. Proposal mode gates destructive actions; approval surfaces are explicit, not implicit.
Every tool call is resolved through auth → role → capability → per-agent grant → execution mode. Default-deny at every layer; misses are logged with a rationale code.
A platform preamble is injected into every coworker’s system prompt and is never part of user input — defending against prompt injection and keeping persona discipline consistent across the workforce.
Decisions, tool calls, and approvals are recorded so the runtime is reviewable end-to-end.
GAID provides badging, issuer, and traceability so contributions from agents are distinguishable, not anonymous.
All code changes flow through pull requests with required CI checks and DCO sign-off before they reach the main branch.
What’s still moving
The platform is a working system, and it is also actively evolving. This section is the honest list — what is in production, what is partially in production, and what is currently specced. Read it as a maturity map, not a sales sheet.
| Area | Maturity | Notes |
|---|---|---|
| Build Studio (5 phases) | Production | Governed lifecycle through ship with sandbox execution, review evidence, code intelligence, and promotion or PR handoff where configured; hardening continues for oversized builds and safer portal upgrades. |
| Coworker workforce, grants, tool gating | Production | Default-deny grants, route-scoped agent identity, immutable directive injection, audit log all live. |
| Archetypes (12 categories, 45 leaf templates) | Production | Bootstrap on storefront setup; sections, vocabulary, finance profile, design system, marketing posture, and workspace-home direction seeded. |
| LDAP / Active Directory / Entra federation | Production | Federation page live; principal linking from upstream identities to internal records. |
| GAID identity issuance & audit | Production | Identifier issuance, authorization decision logging, chain-of-custody traces all in place. |
| Local-first inference (Docker Model Runner) | Production | Bundled with Docker Desktop 4.40+; auto-pull on first run with progress reporting. |
| Operations Map, capacity continuity, capability needs | Production | Operator views and saved preferences live for workforce posture; capacity continuity and capability-needs review route AI follow-up into durable evidence and backlog work. |
| Wiki and managed documents | Production | Global wiki browse/detail, wiki linting, founder-kernel pages, managed document list/detail, lifecycle state, versions, and references are live. |
| Licensing readiness | Production | Compliance licensing workspace and route-specific coworker tools capture factual licensing posture, readiness issues, and investigation evidence. |
| Edge Node — envelope, adapters, Go agent | Early access | Canonical event envelope with change events (Slice 0/1) live on portal ingest. UniFi adapter (controller discovery + clients), ARP collector with MAC-OUI vendor enrichment, and SNMP/LLDP telemetry adapters are shipped. A Go host agent (enroll, heartbeat, host-info, ARP collector) is in place with wire-contract parity tests. Deployment matrix covers single-host, multi-host, and macvlan; air-gapped runbooks exist. Native binaries beyond the Go scaffold and mTLS hardening are follow-on. |
| Capability-tier model routing | Production | Dynamic, capability-tier driven; sensitivity clearance enforced; champion/challenger A/B with promotion gates. |
| MCP tool surface | Production | Backlog, build, evidence, contribution, and feedback all callable as MCP tools under the same gates as in-product coworkers. |
| Hive Mind contribution flow | Production | Three contribution modes; Reusability Check at design time; assessment uses analysis as input. |
| Observability — Prometheus discovery | Production | Estate inventory, scrape-job classification, evidence trails. |
| AI cost governance (EP-COST) | Early access | Anthropic cache telemetry, accurate per-model pricing, BuildPhaseRun + ToolExecution metering, AgentBudgetEvent, rolling thread compaction, phase-boundary summarization, and CLI-pool pre-dispatch rate-limit checks are live. Per-phase cost breakdown surfaces in Build Studio. Budget enforcement (hard stops vs. soft alerts) is the closing piece. |
| Decision Perspective Gate (WWMD) + Persona Voice Layer | Early access | WWMD is the canonical handler for open-question and ambiguity surfaces, returning recommend / arbitrate / escalate / defer with confidence and audit trail; also exposed as an MCP tool. The Persona Voice Layer ships speaches-based STT and admin-configurable per-coworker TTS profiles for spoken decision rationales. |
| Cloud Single-VM (AWS / GCP / Azure) | Early access | Terraform modules for single-VM deployment on AWS, GCP, and Azure are merged on main; the Linux installer runs headlessly inside the VM. Pilots wanted to graduate the path to GA. |
| Portal self-upgrade runtime | Early access | Bundle-hash-driven self-upgrade keeps a long-lived install current with main; canonical-URL middleware handles multi-origin remediation. In-session UX continuity during recycles is the active hardening surface. |
| A2A-aligned coworker runtime | Partial | Internal building blocks present (TaskRun, TaskNode, delegation chains, proposal mode). Refactor to a unified A2A-shaped task envelope is specced and underway. External A2A endpoints are deferred until the internal substrate is task-native. |
| COO-led onboarding | Partial | Onboarding-coo coworker, archetype bootstrap, local-provider setup, and install-mode guidance are live. The MCP onboarding step has known friction; zero-click provider setup is the goal. |
| Improvement loops for every coworker | Partial | Per-agent scoring and instruction phases (learning → practicing → innate) live. Build conventions that feed prompt-level learning back to build specialists are specced; extension to other coworker types is the gap being closed. |
| OpenTelemetry tracing | Specced | Discovery and metrics are live; native OTEL traces are not yet emitted by the runtime, though the architecture supports pluggable collectors. |
| Public A2A endpoint exposure | Specced | Internal substrate must be task-native first; once that is in place, private and public A2A endpoint exposure is a projection rather than a rewrite. |
| Build orchestrator resume after restart | Specced | Phase data persists; resume logic at task granularity after a process restart is tracked work. |
Roadmap and backlog
Beyond the “What’s still moving” table above, the platform has a deliberate roadmap of larger initiatives that are in early access, designed, or under active research. They are listed here so evaluators can see where the platform is heading — not as commitments to a date, but as the shape of the open backlog.
Deployment maturity beyond Windows + Docker Desktop
| Target | Status | Notes |
|---|---|---|
| Windows + Docker Desktop | Production | The current shipped install. PowerShell installer, MSI host-network bridge, auto-pull local model, one-question setup. |
| Linux single-host | Early access | The native Linux installer is code-complete on main; Ubuntu CI exercises the full stack. More distro, reboot, provider, and real-hardware verification reports are needed before GA. |
| macOS workstation | Early access | The macOS Apple Silicon installer is code-complete on main with Docker Desktop and Docker Model Runner support. Real Apple Silicon install reports are needed before GA. |
| Cloud single-VM (AWS / GCP / Azure) | Early access | Terraform modules for AWS, GCP, and Azure are merged on main. The Linux installer runs headlessly inside the provisioned VM; the dedicated runbook adds cloud-specific provisioning, public-URL / TLS, and persistent-storage guidance. Pilots wanted before GA. |
| Cloud-managed services (RDS, ElastiCache, Neo4j Aura, Qdrant Cloud) | Designed — low coupling | Postgres, Redis, Neo4j, Qdrant, browser-use, and AI inference all reach the portal through environment variables. Swapping any of them for a managed cloud equivalent is a configuration change, not a code change. |
| ECS / Container Apps / Cloud Run | Designed — medium coupling | Portal and sandbox containers are deployable as container tasks today. The MSI host-network bridge gets replaced by cloud-native ingress (ALB/NLB, App Gateway, Cloud Load Balancing, or a Traefik/Caddy/nginx front). Inngest can run self-hosted or move to Inngest Cloud. |
| Kubernetes / Helm chart | Designed | Reference architecture covers the Kubernetes path. A first-class Helm chart and operator are tracked work, not yet shipped. |
| DPF-on-DPF production instance | Specced | The production instance the project itself runs on, hosted on the platform. Closes the recursive-self-improvement loop end-to-end. |
| Mobile companion app (iOS + Android) | In progress | React Native 0.83 + Expo SDK 55 + React 19.2 companion app under apps/mobile. Approval surfaces, coworker chat, and offline-cached views are the early targets. |
Open backlog — designed, not yet delivered
Each line is anchored in a dated design doc under docs/superpowers/specs. The order is rough thematic grouping, not priority.
| Initiative | What it brings |
|---|---|
| External customer AI coworker | A storefront-facing assistant separate from internal coworkers, with strong trust disclosure, constrained tool use, customer-safe data access, and adaptive human escalation. GAID-backed trust badging is the future state. |
| Public contribution mode (fork-based PR flow) | Fork-based contribution so installs without upstream write access can still contribute. Replaces the current upstream-write-token model now that the repo is public. |
| Connector factory framework | A repeatable factory for adding integrations (HRIS, ERP, banking, CRM) under the conduit-not-broker stance — customer brings their own account and credentials. |
| ADP / payroll MCP integration | First connector through the factory: payroll feeds, position management, employment lifecycle. |
| Tax remittance | Sales-tax / VAT calculation and remittance flow tied to storefront orders and the finance module. |
| Coworker execution adapter substrate | Unifies the way coworkers dispatch to local LLMs, hosted APIs, and CLI providers (Claude Code, Codex CLI) so adapter-specific quirks stop leaking into the runtime. |
| Routing control / data plane split | Separates routing decisions (control plane) from inference (data plane) so routing changes can be deployed independently and audited as configuration. |
| Orchestration primitives | First-class building blocks for multi-step coworker work — durable handoffs, parallel branches, conditional escalation. |
| Artifact provenance receipts | Signed receipts attached to every produced artifact (design doc, code change, evidence record) so downstream consumers can verify origin and authority. |
| Discovery / fingerprint contribution pipeline | Estate discovery feeds fingerprints back into the hive mind so the next install gets better defaults from the community’s collected experience. |
| Multi-layer topology graph + views | Graph views that span business, application, and technology layers (ArchiMate-aligned) with traversal for impact analysis. |
| Async coworker messaging | Coworker conversations that survive across sessions, devices, and durable background work — not just one chat thread at a time. |
| Browser-use integration | A bundled headless browser MCP service so coworkers can carry out web tasks (form fills, lookups, evidence capture) under the same governance as every other tool. |
| Lifecycle evidence specialist | A dedicated coworker that curates the evidence trail across the lifecycle — making sure compliance, audit, and contribution all draw from the same canonical record. |
| Custom archetype creation and refinement | A path to add and refine market archetypes beyond the bundled catalog, including parameterizable vocabulary, finance profile, design tokens, and worker-home composition. |
| IT service provider (MSP) archetype | Adds a thirteenth archetype for managed-service providers — a frequent customer profile that doesn’t fit the existing twelve cleanly. |
| Local-LLM grading (incremental) | Lets local models grade local work, reducing dependence on cloud providers for evaluation traffic. |
| Build orchestrator resume after restart | Task-level resume of an in-flight build after a process restart. Phase data already persists; the resume logic is the gap. |
| Zero-click provider setup & MCP onboarding polish | Removes the manual paste-and-restart step from MCP setup; OAuth becomes the only required interaction. |
| OpenTelemetry tracing | Native OTEL trace emission across portal, sandbox, coworker runtime, and MCP tool calls — complementing the Prometheus discovery already in place. |
| Public A2A endpoint exposure | Once the internal coworker runtime is fully task-native, expose private and public A2A endpoints so external agents can call into the platform under the same governance gates as in-product coworkers. |
| Improvement-loop coverage for every coworker | Build conventions feed prompt-level learning back to build specialists today; extending the same observe → classify → accumulate → inject → graduate pattern to every coworker is the explicit goal. |
Research and exploration
Areas under active research. They are influencing design today even though no shipped feature depends on them yet.
Standards engagement
Tracking ISO/IEC 42001, NIST AI RMF, the NIST AI Agent Standards Initiative, and the NCCoE concept paper on agent identity and authorization. The platform is intended as a proving ground for TAK and GAID under those frameworks.
Open-source agent identity registries
How GAID-Federated and GAID-Public profiles interact with public issuer accreditation, revocation, and verifier infrastructure outside any single install.
External A2A interoperability
What it takes for the platform to be both a caller of external A2A agents and a callee — specifically how delegation chains and TAK runtime controls cross trust boundaries.
Continuous improvement flywheel
Portfolio-aware observe → normalize → evaluate → propose → govern → execute → contribute cycle that turns every install’s operating data into shared platform improvement.
Honest qualifier: dates are not a contract. Priorities follow what installs actually need and what the hive mind is producing. Specs land in docs/superpowers/specs; plans land in docs/superpowers/plans. If you want the most current view, that is where to look.
Frequently asked questions
Common questions from people evaluating the platform pre-install. The user guide and architecture docs go deeper on each.
Is the platform really open source?
Yes. The repository is public and contributions land via pull request with DCO sign-off. The customizable install is a full source clone — Build Studio and your local IDE share the same workspace.
Does my data leave my environment?
Not unless you opt in. The platform ships with a bundled local model and runs everything on your hardware. External providers are an upgrade with explicit sensitivity clearance per provider; Hive Mind contribution is opt-in and goes through a pull request you review.
Can multiple companies share one install?
No. Each install is one Organization — no multi-tenancy. The cross-company value path is the Hive Mind, not shared database rows.
Do I need a developer to use it?
No for day-to-day business operation. Archetypes, the portal, and AI coworkers are meant for operators. For changing the platform itself, Build Studio is the governed development surface, and customizable installs can pair it with a local IDE while that surface continues to mature.
What if I do not want to run AI locally?
Plug in a cloud provider (Anthropic, OpenAI, others). Set its sensitivity clearance, and routing will pick it for traffic that the clearance covers. Local stays the default for restricted data.
How do I get help?
The in-product COO coworker is the first stop. Beyond that: the user guide is published in the repo, issues and discussions live on GitHub, and the AI coworker development principles document explains how to extend the workforce.
Can I trust an agent’s actions?
Every meaningful action carries an approval surface, a tool grant, and an audit log entry. The platform’s posture is “humans hold authority, agents hold capability, the kernel mediates.” What an agent did, when, and on whose authority is always reconstructable.
What does the install include?
Portal, init container, Postgres, Neo4j, Qdrant, Inngest, Redis, the local model runner, and on-demand sandbox containers. Twelve market categories, 45 leaf archetype templates, purposed coworkers, the skill registry, and a seeded role hierarchy come pre-loaded.
How do I uninstall?
Stop the stack with dpf-stop, remove the Docker volumes (your data lives there — back up first if you want to keep it), and delete the install directory. Nothing is registered outside your machine.
What does it cost?
The platform is free and open source. Cloud provider usage (if you connect external models) is billed by the provider; the platform shows AI spend alongside the rest of your operating costs in the finance module.
What does the “ready-to-go” vs “customizable” install mean?
Ready-to-go uses pre-built images and the guided portal surfaces. Customizable clones the source and shares the workspace with Build Studio plus a local IDE. Same platform either way; customizable is the safer choice for serious source edits while Build Studio hardening continues.
Where do I file an issue or suggest a feature?
The in-product coworker can submit feedback and improvement proposals through governed MCP tools. You can also open issues directly on the GitHub repository.
Who this is for
Small business owners
Enterprise-grade product, finance, and compliance capabilities without enterprise-grade budgets or teams.
Regulated industries
Healthcare, finance, insurance, and similar settings that need audit trails, approval chains, and compliance evidence built in — not bolted on.
IT leaders
One governed platform to model architecture, manage portfolios, and track delivery in lock-step.
Developers and architects
An open platform that treats AI as a core capability rather than a chatbot sidebar — extensible, contributable, and audit-friendly.