Open Digital Product FactoryIn plain terms
One install gives you a website your customers can use, a place to run the work, and AI coworkers that already speak your line of work. You approve the important moves, and everything stays on your own computers.
Three ways in
Use it · Resell it · Understand it
Run your software & platforms business
Move from inquiry to proposal to milestone billing, with each client’s estate kept clean and isolated.
See the value & capabilities ↓Package it for clients
One platform you set up per client — brand it, support it, repeat for the next client. No custom app each time.
Explore the reseller path ↓Inspect the architecture
How it's built, how every AI action is approved and logged, and where it stands against emerging AI-agent standards — auditable, not a black box.
See under the hood ↓How the work flows
How a software & platforms business works
Inquiry → demo / pilot / partnership → proposal → engagement → live install and ongoing support. The platform powering its own go-to-market is the proof.
Scroll the diagram sideways to read every stage →
DPF sets all this up for you out of the box — your public website, the words your AI coworker uses, your scheduling, your pricing, and the licence checks you need all come ready.
Start to finish
Your work, one step at a time
Every business finds customers, takes the work, does the job, gets paid, and keeps them coming back. What changes is the step that makes or breaks your kind of business — highlighted below.
Trust & licence checks — across every step
- S1Marketing
- S2Inquiry / contact
- S3Send to product backlogmake-or-break
- S4Engagement
- S5Live install
- S6Support & co-sell
Your AI coworker — turns enquiries into work, in your words
The pain today
Problems we solve
- Prospects look like customers. Vocabulary distinguishes users, developers, and enterprise prospects from end-customers.
- Inquiry → backlog is manual. A “send to product backlog” action turns a lead into a tracked item on the product.
- Pilots and partnerships are invisible. Service agreements track pilot terms, feature requests, and co-sell outcomes.
- Platform-speak leaks to customers. Internal product language stays separate from customer-facing copy.
Out of the box · each tied to a part of DPF
What DPF gives you
- Prospect intake for company size, team, and current operating-model pain. Website & enquiries
- Inquiry-to-backlog creating a tracked item on the product itself. Website & enquiries
- Pilot & partnership tracking via service agreements. AI coworker & workflow
- Portfolio decomposition across platform, build, and coworker offerings. AI coworker
- Two vocabularies — product language internally, plain business language for customers. AI coworker
What it looks like
A look at the real screens
A few of the screens a software & platforms business actually uses — the work board, and an AI coworker proposing the next move. Nothing happens until you approve it.
Inquiry
Proposed
Engaged
Billed
The internal workspace home — demand becomes routed, trackable work.
The coworker proposes; nothing consequential happens until you approve.
The mobile app — where this gets even better
Even when the work isn’t in the field, you are. We want a pocket app that pings you when a coworker needs a yes or no on a risky step, and lets your customers book, track, and pay from your own branded app.
One generic native iOS/Android app (published by Arcamanus LLC) that connects to your own install and lets the platform drive its look and features — so field techs, customers, and you each get the right screens without a separate app per business.
Where it stands today: the foundation is real and in the codebase — a React Native/Expo app shell (native shell + install manifest + offline form/screen renderer), a REST API, and secure sign-in. The end-user experience — persona-aware screens, connecting one app to any install, push notifications, and App Store / Play delivery — is the next phase and not yet available. We’re building toward field dispatch and owner approvals first.
Engagements
For builders, resellers & architects
Under the hood — how DPF builds this
The rest of this page is the technical detail for people who extend, resell, or evaluate the platform. In one line: one install becomes a governed system for your whole business — the business type shapes everything, every AI action is approved and logged (the TAK runtime), and each AI coworker carries a checkable identity and an evidence trail (GAID). Most owners can stop above.
How it's built
One business type generates the whole setup
The business type you pick at setup is the single source of truth (StorefrontConfig.archetypeId in the data model). From it, DPF generates the public website wording, scheduling defaults, finance assumptions, licence hints, the words each AI coworker uses, and the direction of the mobile app — which is how one platform covers many business types without a custom app for each. (For builders, the precise internal term is the “archetype”.)
StorefrontConfig.archetypeIdactivationProfile · axes · vocabularyStep 2 of 5 · What kind of business is this?
Your choice becomes StorefrontConfig.archetypeId — everything else generates from it.
Public storefront, vocabulary and CTA generated from the archetype — no page-building.
For architects & standards reviewers
DPF as a reference implementation
DPF is a working prototype for two proposed standards — not a claim of full present-day conformance. TAK governs what an agent may do; GAID governs who the agent is and what evidence follows its actions. Here is what is real today, what is partial, and what is still proposed — the gaps are mapped, not hidden.
TAK — Trusted AI Kernel
The runtime-governance harness: authority mediation, tool-execution gating, human-in-the-loop, memory limits, and audit/evidence — enforced as an agent operates.
GAID — Global AI Agent Identification & Governance
Who an agent is, the claims it carries, and how its actions are identified and traced — identity documents, badges, authorization classes, and action receipts.
Implemented now
- Route-scoped AI coworkers — each route gets a purpose-built coworker with its own tools and vocabulary
- Tool authority = grant ∩ user capability — every tool exposure filtered by user authority, mode, and external-access posture
- Proposal-mode gated actions — consequential actions break the loop and return an approval payload instead of executing
- Tool-execution audit logging — every call written to
ToolExecution— agent, user, tool, params, result, route, duration, audit class - Archetype-driven UX & vocabulary — storefront, scheduling, finance and compliance defaults generated from one archetype
- Internal agent registry — stable identifiers, model bindings, supervisors, delegates, grants, HITL defaults
Partially implemented
- TAK runtime transparency — an Authority & Audit workspace with a supervisor-ready Agent Card snapshot
- Agent Card / AIDoc projection — the registry approximates an AIDoc — not yet signed or resolvable
- Stable internal agent identity — platform-local today, not yet canonical GAID identifiers
- HITL tier metadata — carried per agent, not yet one uniform runtime policy engine
- Delegation & authority modeling — supervisor & delegation recorded, not yet a receipt-backed chain
- Chain-of-custody trace — agent, user, route and tool recorded; not yet end-to-end across boundaries
Planned / proposed
- Signed / tamper-evident receipts — cryptographically verifiable receipts for consequential actions
- GAID public/private namespaces — explicit private vs externally-accredited public identity scopes
- Public verifier metadata — published A2A Agent Cards and external receipt-status endpoints
- External certificates & status — issuer validation and public status services for exposed agents
- Capability & governance badges — evidence-backed assurance levels
- Repeatable conformance suites — automated TAK & GAID test packs preserved as evidence
Grounded in the platform’s own first-pass assessment: TAK / GAID conformance assessment · TAK · GAID · governance white paper. DPF is the proving ground where these ideas are exercised in real workflows.
For architects · the evidence trail
Every AI action is identified and logged
A supervisor-ready snapshot of any coworker: who it is, what it may touch, the mode it runs in, and the evidence behind its last action.
engagementA supervisor-ready snapshot: who the agent is, what it may touch, and the evidence behind its last action.
For partners, MSPs & consultants
A repeatable vertical you can resell
Package once, deploy per client.
DPF turns a business type into a complete, ready-to-run setup. Instead of building a custom app for every client, you install one platform, pick the business type, brand it, and support it — the same way for the next software & platforms client and the one after that.
Partner & contribution path- Archetype-based configuration, not custom code per client
- Local install on the client’s own hardware — you own the support relationship
- Reusable industry patterns shared through the opt-in Hive Mind
- Governed coworkers and audit trails regulated-sector clients require
Ready to see it for your business?
Install on your own computers in minutes — the setup asks one question and sets up everything else for software & platforms automatically.
Install All business typesPlain-language checked — the everyday copy on this page reads at about a Grade 9 level (Flesch–Kincaid Reading Ease 44). We hold business copy to a high-school reading level; the architecture and standards sections are intentionally more technical.