Rule
When DPF needs a capability an open-source project already implements, the answer is to own it and blend the functionality into the platform, not to run that project as a bundled service beside DPF.
The dependency surface only shrinks. Every package, container image, always-on service and vendor subscription is a dependency. A proposal that adds one must name what it retires, and should leave the platform with fewer dependencies than before. When an option adds a dependency and another option absorbs the capability into substrate the platform already owns, the absorbing option is the default. The adding option has to make its case.
The refactor budget follows from this. Founder-funded shared platform work allocates roughly 80% to refactoring, integration and reliability repair, 20% to new capability. Founder direction reconfirmed 2026-10-11: execution reliability is the primary investment until a maturity review explicitly changes it. Measure progress through fewer broken-tool retries, lower time/token waste and reliable completion.
This is a cumulative planning target, not a per-task quota. Funding owner and work purpose govern it, not the install, executor or administrator’s token. Organization/archetype work retains its owning scope’s policy (default 20% refactoring / 80% new capability). Unknown funding scope remains unresolved; do not assign the founder’s budget by guessing. Current explicit owner direction supersedes older guidance in that scope; identify overlapping plans and record their reconciliation before executing conflicting work.
Why
Founder direction, 2026-08-23: “I would like to absorb, not use as delivered. This is the entire point of this platform, to absorb.” And on the budget: “all the parts of the platform are here, but [need to be] well integrated / refactored to form the hybridized result I envision.”
Founder direction, 2026-09-22, on evaluating an office suite: “We want absorption, and want to limit dependencies. WWMD should be clear on this direction when facing options.” At core tier, weight 0.6, scoped to one ring, this principle lost to other principles on exactly the decisions it exists for.
The platform’s marginal value is no longer in adding parts. It is in hybridizing the parts that already exist.
A third-party stack beside the platform is an appendage. The failure this prevents is a second store beside a canonical model. For identity, that is a second user store beside the canonical principal, which breaks convergence and creates parallel truth: “identity needs to be tied and integral with the agent and people, not separated by a loosely coupled software stack.” Every dependency is also a lever someone else controls: a release that breaks the build, a digest that rots, a licence or price change. The dependency-diet measurements behind EP-8DC217EB (a 4.17 GB image, 2,000 resolved packages) show what an unexamined surface costs.
How to apply
- When planning an epic or slice, put most of the capacity into consolidating duplicate concepts, collapsing loosely coupled seams, and making capabilities native rather than adjacent.
- Treat “add a new subsystem beside the existing one” as the disfavoured option that needs justification. Treat “absorb it into the existing spine” as the default.
- When a capability cannot be absorbed as source, bring it into infrastructure the platform owns:
- A DPF-built, pinned tool image that runs only when called, not an always-on third-party service.
- It is invoked through a platform contract, so it can be replaced without touching callers.
- It should retire other dependencies (for example, one document engine replacing several parsing packages).
- Rented services and subscriptions sit at the bottom of the ladder. Choose one only when there is no absorbable or self-hostable path, and record it as a gap to close.
- Licence terms travel with absorbed source. A permissive licence permits absorption and usually requires attribution, so carry the licence notice with the code.
- Update the stated allocation in design docs rather than carrying an older ratio forward silently.
- Federation and interoperability stay. The rule governs where functionality lives. It does not mean refusing to interoperate.
Evidence-led ecosystem absorption
Analysis tools can help recover the business behavior an organization needs from existing software. Treat their findings as evidence for the existing intake, coverage assessment, and delivery process. Observed behavior, inferred behavior, and verified DPF coverage remain distinct. Discovery does not authorize migration or establish product coverage.
Apply the owner-scoped investment allocation above to canonical identity, evidence, governed execution, inference, and shared human/coworker surfaces. Absorb selected implementation behind replaceable platform contracts; qualify underlying engines separately. A fast model or a broad tool catalog does not justify a parallel business model, duplicate assessor, or permanent adjacent stack.
WWMD sets platform direction. The organization decides adoption and accepted dependencies in WWWD; profession standards and qualification belong to WSID. Customer artifacts stay within the organization’s data boundary. Share only permitted, sanitized requirements and verified reusable methods.
The REA research and phased proposal applies this direction to ecosystem analysis and future inference hardware. Its pilot slices require live reconciliation and qualification before implementation.
Related
prefer-self-hosted-infrastructure · architecture-over-shortcuts · verify-substrate-before-proposing-new · substrate-cleanup-before-substrate-addition · one-home-per-capability · single-source-of-truth