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 automotive services business
Capture urgent jobs, dispatch the right technician, hold maintenance plans, and invoice from the field.
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 automotive services business works
Scheduled mobile service (glass, mechanic, detailing, tyre) is booked and paid at completion; roadside and lockout work is real-time emergency dispatch with no pre-booking.
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
- S1Inquiry / emergency call
- S2Quote (VIN → parts)
- S3Schedule or dispatch nowmake-or-break
- S4Service at the vehicle
- S5Settle payment
- S6Record & follow-up
Your AI coworker — turns enquiries into work, in your words
The pain today
Problems we solve
- Glass quotes need VIN-to-part matching. The VIN is captured up front so parts resolution and pricing aren’t a guessing game on the phone.
- Mechanics dispatch blind. Vehicle year/make/model and the symptom ride along with the job.
- Roadside isn’t an “appointment”. A real-time, transactional dispatch mode handles lockouts and tows without forcing them into a booking calendar.
- Post-install compliance goes undocumented. Auto-glass ADAS recalibration is tracked as a step, not an afterthought.
Out of the box · each tied to a part of DPF
What DPF gives you
- VIN & vehicle-context intake feeds parts resolution and an accurate quote. Website & enquiries
- Two dispatch modes — scheduled mobile service and real-time emergency response. Work board
- On-site settlement pay-at-completion for scheduled work, instant capture for emergencies. AI coworker & workflow
- Compliance overlays ADAS calibration for glass, DOT hours for towing, bonding for locksmiths. Licence & safety checks
- Vehicle records so the next service or callback has the history. Customer records
What it looks like
A look at the real screens
A few of the screens a automotive services business actually uses — the work board, and an AI coworker proposing the next move. Nothing happens until you approve it.
New
Scheduled
On site
Invoiced
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
For automotive services, the phone is where the work happens. We want a field app that shows the next job, maps the way there, takes photos and a signature, and makes the invoice on the spot — even with no signal.
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.
Today
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.
dispatch-coordinatorA 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 automotive services 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 automotive services automatically.
Install All business typesPlain-language checked — the everyday copy on this page reads at about a Grade 8 level (Flesch–Kincaid Reading Ease 51). We hold business copy to a high-school reading level; the architecture and standards sections are intentionally more technical.