Owners and operators
Run customers, work, money, people, assets, and follow-up in one coherent workspace instead of stitching together a dozen disconnected tools.
Begin with your operating model
Start with the business, not the software.
Choose what your organization does and DPF shapes the public experience, everyday vocabulary, workflows, finance assumptions, and coworker context around that choice. The detailed catalogue groups more than 100 packaged business types into approachable paths without exposing internal taxonomy first.
Regulated and licensed teams
Keep approvals, controls, obligations, evidence, and decision receipts close to the work that produced them.
Builders, partners, and resellers
Extend a shared platform through governed source changes. Build Studio is available, but external development clients and normal pull requests remain supported paths.
One install, three working surfaces
The customer journey and the work behind it stay connected.
DPF is not a chat box beside a collection of apps. It is a shared operating model where customer activity, internal work, and governed coworker assistance meet the same company primitives and authority rules.
How value moves through the platform
Customer experience
Discover, request, book, buy, pay, track, and communicate through a business-shaped public surface.
Operating workspace
Turn demand into owned work across customers, money, people, assets, knowledge, and compliance.
Purposed AI coworkers
Gather context, draft, reconcile, route, and prepare decisions within role, route, and tool authority.
One company vocabulary
One authority model
One evidence trail
One governed change path
Where the work actually happens
Work runs in Workrooms, and a Workroom knows what kind of work it is.
A Workroom is a focused place where authorized people and AI coworkers coordinate toward one named outcome. It is not an open chat channel. It carries a purpose, an outcome, an accountable owner, an authority level, a sensitivity ceiling, measures, and a rule for when it closes. Conversation alone never completes one — closing a room produces an outcome packet built from decisions, artifacts, receipts, evidence, and the work left unresolved, each remaining item with an explicit disposition.
The room bounds what may happen
A room is convened with a collaboration shape — specialist alignment, approval sign-off, outward review, consequential change, escalation, or craft stewardship. The shape decides which roles must be present before the room may act, and whether sensitive work requires stronger authentication. A missing approver is a stated gap, not a silent pass.
The work sets the pace, not the job title
How hard and how fast a coworker pushes is derived from the shape of the work, what the business does, and the clock — read from the operating hours you already configured. The same coworker behaves differently drafting a note on a Saturday and releasing a payroll run on its due date.
Finite work closes; standing work cycles
A finite room closes when its bounded outcome is satisfied. A standing room supports recurring work, and each cycle carries its own objective, measures, stop conditions, and structured outcome — so an idle standing room reads as healthy rather than as finished.
The rule that makes this predictable: a derivation may tighten, and may never widen. A room can make a coworker more careful or more urgent than its own setting. It can never make one act more freely than its authority allows. Closing time changes how loudly a coworker follows up; it never changes what a coworker may do — and security incidents, platform health, and a late field appointment are never quietened at all.
Customers and demand
Accounts, engagement, pipeline, quotes, orders, campaigns, and the next action.
Work and delivery
Portfolios, products, epics, backlog, schedules, operating cases, and ownership.
Money and assets
Budgets, costs, invoices, inventory, fulfilment, and lifecycle context.
People and authority
Human roles, coworker identities, grants, delegation, approvals, and escalation.
Knowledge and decisions
Source-traced company context, professional guidance, principles, and decision history.
Compliance and evidence
Obligations, controls, proof, posture, licensing readiness, and chain of custody.
Autonomy is earned, not assumed
A coworker can recommend. Authority still decides what happens.
DPF treats human identity, coworker identity, tool authority, and evidence as one system. The model can help reason about work; it does not gain permission merely because a user asked in natural language.
- User intentrequest and context
- Authority gaterole ∩ grant ∩ policy
- Purposed coworkerbounded tools and scope
- Decision perspectiveWWMD platform evolution and ecosystem · WWWD your business stance · WSID profession craft — scored, cited, logged
- Risk decisionact, propose, escalate, or defer
- Human approvalwhen impact requires it
- Outcome and receiptwho, what, why, authority, and result
- Autonomy dialsearned trust (shadow → autopilot) and proactivity (quiet → assertive) set initiative, never authority
Default deny
A tool is unavailable until both the coworker grant and the acting user’s capability allow it.
Risk raises the human surface
High-impact work pauses for an explicit proposal, approval, escalation, or refusal.
Identity survives delegation
The user, coworker, delegated authority, tool call, and result remain linked.
Judgment is inspectable
Principles, company knowledge, and professional sources support explainable decisions.
Three corpora, not one opinion
Platform doctrine, your organization’s own authored stances, and the profession’s recorded craft stay separate — scored, cited, and logged. Your business decisions never inherit platform judgment as authority.
The corpus grows as you decide
Your organization’s stances are authored by your organization. A decision made once becomes context the next one is judged against.
What the gate actually checks
A recommendation is not a permission.
Consulting a corpus produces a recommendation. Permission is decided separately, when the coworker reaches for a tool. Every governed tool call is classified from the tool’s own declared consequence — on the central execution path, so the classification covers every call rather than a hand-maintained list of names.
Three consequence classes
A call reads only, changes internal state, or is consequential — it spends money, reaches a third party, changes who may act, or destroys state.
Two independent checks
The authority intersection (coworker grant and the acting user’s capability, default deny) and the autonomy envelope, which decides whether a human turn is required at all.
The stricter one wins
A pace setting cannot buy autonomy the envelope would deny, and an autonomous envelope cannot act on work whose shape said it must be proposed.
Denials are named
A missing decision, a missing envelope, a tripped stop condition, a missing verification receipt — a refusal tells you what to fix, rather than failing generically.
Corpus coverage is an autonomy input
A thin professional corpus does not produce a bad recommendation. It produces an escalation. A coworker with nothing recorded to reason from keeps asking you, correctly.
Floors nothing crosses
Money leaving the business and anything that goes public always come to a person, at every setting. Regulated work carries a verification requirement no posture can trade away.
Priority is tunable, and what ran is reviewable. Operators express intent in plain terms — lean toward quality, cost, or speed — and the platform compiles that into explicit policy adjustments against the routing contracts that already exist. It feeds routing as defaults, so an explicit setting and the local-only sovereignty switch still win; it fails open, and a balanced posture makes no adjustments at all. The outcomes view then compares what the posture asked for against what actually ran, and distinguishes an infrastructure failover from a deliberate trade-off — one is a fault to fix, the other is the system doing what you asked.
Standards for accountable autonomy
Three different questions. Three verifiable answers.
DPF separates identity, job fitness, and permission to act. A strong model score can be useful evidence, but it does not show that a particular AI coworker is qualified for a real job with its data, tools, risks, and oversight requirements.
GAID · Who is it?
Identify the coworker.
Bind a durable identity to the active operating profile, advertised claims, status,
and evidence.
Read the identity standard →
TAK-JSI · Is it fit for this job?
Qualify the whole working system.
Assess the coworker for a versioned job, activity, data scope, and risk context—then
revalidate when a material part changes.
Read Job-Specific Intelligence →
TAK · May it act now?
Enforce runtime authority.
Intersect the user’s authority, coworker grants, qualification, policy, data
constraints, risk, and required oversight for each action.
Read the runtime standard →
Current posture: TAK, GAID, and TAK-JSI are open working drafts, with DPF as their initial implementation prototype. They define proposed conformance evidence and a path toward candidate specifications and independent assessment; they do not claim that DPF or its coworkers are presently accredited or certified.
Honest product posture
Useful now, still becoming more complete.
DPF is an active open-source platform. The overview separates working platform contracts from areas still being hardened or verified, so a vision statement is not mistaken for current product behavior.
Implemented now
Working platform contracts
- Single-organization, local-first deployment with a public site and internal operating workspace.
- More than 100 packaged business types with business-shaped vocabulary and defaults.
- Purposed coworker registry, governed tool execution, approvals, and audit evidence.
- Portfolio, backlog, customer, workforce, finance, compliance, knowledge, and platform operations.
- Build Studio as a governed development and evidence surface, alongside supported external contributor paths.
- Self-upgrade, recovery, CI, migration, and pull-request contracts for platform change.
Still moving
Active maturity work
- The native mobile companion is a documented direction, not a generally available application.
- Native Linux and cloud single-VM installers remain early access pending broader real-host evidence.
- Build Studio continues to improve reliability, right-sized workflow, and autonomous phase handoff.
- Public and federated agent identity profiles remain a standards and interoperability journey.
- TAK-JSI defines the job-qualification direction; DPF does not yet operate the full assessment, credential, surveillance, and revalidation lifecycle.
- Individual integrations advertise capability support; unsupported operations must remain explicit.
Deployment choices
Choose a machine for the way you will run DPF.
Windows and Apple Silicon macOS are the two tested customer targets. Provider-assisted operations use approved external AI and need no dedicated GPU. Local-first operations keep primary AI inference on the host and need more model memory.
Windows 10 / 11
Guided PowerShell installer for Docker Desktop with the WSL2 backend.
Provider-assisted operations
32 GB system RAM · 1 TB NVMe SSD · no dedicated GPU required
Local-first operations
64 GB system RAM · 2 TB NVMe SSD · 24 GB GPU memory supported; 32 GB recommended for a new purchase
macOS Apple Silicon
Native shell installer with one shared memory pool for the CPU and GPU.
Provider-assisted operations
32 GB unified memory · 1 TB SSD · no separate GPU required
Local-first operations
64 GB unified memory practical · 128 GB for larger models or combined operations and development · 2 TB SSD
Native Linux
Docker-based host path for contributors and pilot operators. Validate the exact GPU backend before buying hardware.
Linux install guide →Cloud single VM
Single-tenant VM deployment patterns for AWS, Google Cloud, and Azure.
Cloud install guide →
Operations and development are different workloads. Customer operations
do not need coding-workstation capacity or Build Studio. Choose customizable only when the
host will also do serious source work, builds, tests, or local coding-model evaluation.
Compare current Windows and Mac machines in the complete hardware guide.
Choose the depth you need
One documentation system, several reader paths.
The public overview explains the system. Canonical guides own the operational and technical detail. This keeps one fact in one place while still giving operators, installers, builders, and reviewers an obvious next step.
Evaluate
Business catalogue
See how the platform changes for the organization you run.
Operate
User guide
Setup, daily work, coworkers, compliance, and platform administration.
Install
Hardware and installation
Compare the two AI deployment models, current Windows and Mac machines, and the guide for each tested host.
Understand
Architecture and standards
System boundaries, data, identity, governance, deployment, and conformance.
Inspect intent
Specifications
Approved design direction and the contracts implementation should satisfy.
Contribute
Contributor rulebook
Architecture, worktrees, verification, documentation impact, and delivery rules.
Common questions
Short answers before you go deeper.
Does company data leave the install?
DPF is local-first. Your organization data stays inside its dedicated install unless you deliberately configure an external AI provider, integration, or contribution path. Those paths remain subject to platform authority and audit controls.
Can several companies share one DPF database?
No. One install represents one organization. Cross-install learning moves through governed, opt-in contribution rather than shared tenant rows.
Do I need Build Studio to change the platform?
No. Build Studio is the in-platform governed development surface. Customizable installs also support normal editor and external agent-client workflows, with the same pull-request, DCO, CI, and verification expectations for upstream changes.
Are coworkers allowed to take actions without asking?
It depends on the user’s authority, the coworker’s grants, the tool’s declared consequence, risk policy, and the autonomy envelope on the work. High-impact work has approval floors; unsupported and denied actions must remain explicit. Two floors hold everywhere: money leaving the business and anything that goes public always come to a person. Pace settings change how persistently a coworker follows up, never what it is allowed to do.
Why is a coworker behaving differently in one room than another?
Because pace is resolved from the work, not from the coworker’s job title. The shape of the room, what your business does, and the clock all feed it — so the same coworker is more urgent on an escalation than on standing curation, and quieter when the business is closed. Each room’s Pace and priority panel names the layer that decided and why. A room can only make a coworker more careful or more urgent; it can never widen what the coworker may do.
Where do I see what the coworkers actually decided?
Every governed outcome writes a receipt — who acted, what they did, why, under whose authority, and what resulted. The Coworker Decision Engine shows the decisions and the open reviews waiting on you; the proactivity roster shows every coworker’s current level; the priority outcomes view compares what was asked for against what actually ran. Where the audit trail has nothing to say, these surfaces say so rather than guessing.
Is everything described here generally available?
No. The maturity section explicitly separates implemented contracts from active direction. Host status is also labeled in the install section. Detailed specifications describe intent; the user guide describes current operator behavior.
Where should I report a problem or suggest an improvement?
Use the project’s GitHub issues. Include what you expected, what happened, and which host or platform route was involved.
See the platform through your business.
The clearest next step is not a feature matrix. Pick the kind of organization you run, see the operating pattern DPF starts with, and then choose an install path when the fit is clear.