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 catalogue groups 107 packaged business archetypes across 25 industry categories into approachable paths without exposing internal taxonomy first. Each archetype provisions its own value streams, the Workrooms its stages run in, and the coworker jobs that staff them.
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
87 defined roles across nine value streams 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. Governed tool calls are classified from the tool’s own declared consequence on the central execution path, rather than from a hand-maintained list of names. Coverage is reported as a governed metric, and not every gate enforces yet: some run in shadow mode, recording what they would have refused, while evidence accumulates.
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.
Working drafts, with implementation evidence
Four cornerstones for accountable AI delegation.
DPF is a working platform and the initial test bed for four proposed standards for governed AI. Existing controls, partial implementations, shadow observations, and remaining assessment work are recorded separately. Each standard answers one question. Publishing a draft does not prove that its controls are implemented or effective.
The problem the standards answer
Repeated approval prompts can lose their value.
Per-call approval asks people to inspect many routine actions. Blanket permission reduces interruptions but leaves more work inside the agent’s standing access. Both approaches need controls that bound what the agent can reach and whose authority it may exercise.
Prompt review has limits
Anthropic reports field rates of 97% approval for permission prompts and 39% rejection for plans. Separately, its controlled study of 1,053 paid testers found that people caught a dangerous command 13.6% of the time, falling to about 5% after fifty or more prompts. These are different populations and tasks; they do not prove that plan review or GPP is safe. See the vendor report.
Blanket access needs boundaries
Broad credentials increase what an agent can reach. Skipping prompts therefore needs other enforced controls: isolation, scoped credentials, and an audit trail. A mode name alone does not establish authority or containment.
A filter is not an authority
A classifier can help triage tool calls, with performance that must be measured for its setting. Its prediction is one input to a control system; the owning authority, policy, and enforceable access boundary must still be established.
Proposed GPP approach: a scoped decision, enforced at each call. A person or governed policy decides whether a class of tool use is admissible for a piece of work. The proposed GPP contract requires the runtime to enforce the resulting envelope on each call. DPF currently records GPP permit verdicts in shadow mode; no GPP binding is yet enforced. Existing authority checks and approvals remain distinct controls. Sources, dates, and the limits of each figure are in the market and thought-leadership brief.
Standards for accountable autonomy
Four different questions. Four verifiable answers.
DPF separates identity, job fitness, who decided, 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, or that anyone with the authority to do so agreed it may act.
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 →
GPP · Who decided this may happen?
Bind decisions to tools.
Pair a gate in the authority that owns the decision — platform, organization, or
profession — with the exact tools it admits, for one stage of one kind of work.
Read the Gated Permissions Process →
TAK · May it act now?
Enforce runtime authority.
Intersect the user’s authority, coworker grants, the GPP envelope, qualification,
policy, data constraints, and required oversight for each action.
Read the runtime standard →
Connect the model to the working system
Model-based systems engineering has long described complex systems as connected models of requirements, structure, behaviour, and verification. DPF applies that approach to governed agent work: work shapes, stages, scoped decisions, tool capabilities, coworkers, and receipts are related model elements. Some declarations drive the platform today; the GPP realization annex identifies which modeled controls are implemented, shadow-only, or still missing. The proposed binding connects who may decide with what may run. Its SysML v2 mapping and model-to-runtime checks describe a path to verification, rather than a claim of complete execution, full interchange, or historical novelty.
Principles guide judgment within the scope that owns the question; policies determine which actions are permitted. A recommendation is evidence for a decision, not permission to execute it. The working drafts compose established modeling approaches — SysML v2, DMN, BPMN, and PROV — rather than inventing a new modeling language. Read the modeling crosswalk, the proposed decision contract, and the GPP notation.
Current posture: TAK, GAID, TAK-JSI, and GPP are open working drafts, with DPF as their initial reference implementation. 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. Publishing a clause or a diagram does not establish that its control is implemented — each GPP element is listed with its current mode (enforced, shadow, or not yet built) in its realization annex. Portable executable contracts, independent assessments, published efficacy measures, and Hermes and Cursor demonstrations remain work in progress.
Standards family map
Gated Permissions Process (GPP)
Market and thought-leadership brief
Standards contribution roadmap
Standards conformance
Trusted AI agent governance white paper
Word editions are dated snapshots. The white paper is discussion draft 2.2, generated on October 16, 2026. The other Word editions were generated on October 1–2; use the linked Markdown drafts for the current sources. The GPP Word edition contains draft 0.8 while its current Markdown source is draft 0.19. Download delivery, source currency and runtime conformance are separate checks; the remaining refreshed editions are tracked work.
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.
- 107 packaged business archetypes with business-shaped vocabulary, value streams, and defaults.
- A registry of 87 purposed coworker roles (40 active), governed tool execution, approvals, and audit evidence.
- Tool reach narrowed by Workroom, with enforced organization-and-profession alignment and escalation gates on consequential tools.
- 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.
- A Cloudflare-fronted managed option is in architecture research; it keeps one isolated DPF installation per customer and is not a pooled SaaS claim.
- 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.
- GPP is a working draft. The Workroom-shape gate runs in shadow mode. Gate-minted, signed permits are recorded on every outward, authority-changing or irreversible call but not yet required; enforcement is switched on one binding at a time, and none is enforced yet. GPP efficacy measures are not yet published.
- 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
A compact Mac mini can host your business operating system, with DPF and business records on your own machine.
Provider-assisted operations: Mac mini with M6
32 GB unified memory · 1 TB SSD · everyday operations with approved external AI providers
Local-first operations: Mac mini with M5 Pro
64 GB unified memory · 2 TB SSD · size the local model and concurrent work before buying
Larger local AI workloads: Mac Studio with M5 Max
128 GB unified memory · 2–4 TB SSD · a candidate for document-heavy professional firms, including law firms
The M6 mini tops out at 32 GB. This is a suggested operations configuration, not a measured guarantee for every business. Consider 128 GB for larger models or combined operations and development.
macOS hardware and install guide →Native Linux
Assisted pilot: Ubuntu Server 24.04 LTS, x86-64, on a dedicated VM or server. Uses Docker Engine and Compose v2; Docker Desktop is not required.
Provider-assisted starting point: 8–12 CPU cores, 32 GB RAM and a 1 TB SSD. No GPU required. Bash installer available; customer validation pending.
Linux pilot guide and acceptance checklist →Cloud single VM
Single-tenant VM deployment patterns for AWS, Google Cloud, and Azure.
Cloud install guide →Managed cloud
One isolated DPF cell per customer, with Cloudflare evaluated as a replaceable edge and routing provider.
Read the managed-cloud design →
Size for your business workload. Day-to-day operations do not carry the same
memory demand as continuous platform development. On a customizable install, embedded Build
Studio can handle supported changes without separate Claude or Codex apps. Builds, tests,
previews, and local coding models still need capacity wherever they run; a 32 GB operations
recommendation does not include a full development workload.
Compare Windows, Mac and Linux sizing 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 AI deployment models, Windows and Mac machines, and the recommended Linux pilot target.
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.
Why not just ask me to approve every AI action?
Because people stop reading. Vendor data shows users approve the overwhelming majority of per-call prompts and rarely catch a dangerous one buried among them, so many switch approvals off. The proposed GPP approach asks for a decision where it carries information — for a bounded class of work, by the authority that owns it — and requires enforcement on each call. DPF records GPP verdicts in shadow mode today; existing authority checks and approvals are separate. See the evidence brief.
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.