Attach it
Upload the required document directly into the AI interaction.
How DCPF Works
Controlled handoffs keep Research, Knowledge, Runtime, Governance, and human decisions distinct.
DCPF Works Through Controlled Handoffs
DCPF organizes sustained AI-assisted work by separating discovery, preservation, execution, and Governance into distinct responsibilities. The value is not simply in naming four frameworks. It comes from keeping their responsibilities distinct and making the handoffs between them deliberate.
Research discovers. Knowledge preserves. Runtime executes. Governance guides.
Information does not move automatically from one responsibility to the next. Research produces evidence for review. People decide what evidence is accepted. The Knowledge Repository preserves what the project is prepared to rely upon. Runtime uses the relevant approved Knowledge for the current task. People then review the resulting Project Output and decide what happens next.
DCPF is experimental.
DCPF has demonstrated promise through its development work, practical applications, and training practicums, but it has not been broadly or independently validated across domains, organizations, AI systems, or production environments. Use this workflow first in a controlled, low-risk setting, validate it for your own domain and environment, and retain human judgment, verification, and accountability at every handoff.
The Core Operating Path
A complete DCPF cycle can be represented as a simple sequence. Governance remains active throughout the workflow, but DCPF does not require a complete standalone Governance Repository before the project begins.
Human Defines the Work → Build the Relevant Artifact and Define Applicable Governance Controls Within It
→ Execute Research or Runtime → Human Review / Acceptance → Preserve Accepted Knowledge When Applicable
→ Feedback / Update the Appropriate Framework and Governance Repository as Needed
Governance Operates Across the Entire Workflow
Governance is not the last box in the sequence. It establishes the operating conditions that influence Research, Knowledge, Runtime, and the standards applied to their outputs.
People make project standards, boundaries, acceptance criteria, validation expectations, and decision rights explicit while building the artifacts where those controls operate. When a control should persist beyond one artifact or execution, preserve it in the Governance Repository for consistency, reuse, versioning, and oversight.
The Governance Framework guides. Building artifacts reveal additional Governance controls. The Governance Repository preserves recurring Governance.
Step by Step: How Information Moves
Step 1: Define the Need and the Conditions for Work
The process begins with a human-defined need: what the project must learn or accomplish and how the resulting work is expected to be used. Applicable Governance establishes the source boundaries, quality expectations, review conditions, prohibited practices, validation requirements, and decision rights that should shape the work.
Human responsibility: define purpose, boundaries, acceptable practices, and the conditions under which work may be accepted.
Step 2: Research Produces Evidence
A Research Request converts the information need into a deliberate investigation. It tells the AI what must be learned, which evidence may be used or prioritized, what the scope and boundaries are, how uncertainty or conflicts should be handled, and how the Research Output should be organized and documented.
AI responsibility: perform the authorized investigation and produce documented evidence for review, not declare its own findings to be Accepted Knowledge.
Step 3: Human Review Changes the Status of Information
A Research Output remains evidence until the applicable human review and acceptance decision occurs. People inspect coverage, source quality, documentation, uncertainty, conflicts, gaps, and Governance compliance. They may accept, revise, return material for additional Research, exclude it, or preserve only the accepted portions.
Critical rule: information does not become Accepted Knowledge merely because an AI found or produced it.
Step 4: The Knowledge Repository Preserves Accepted Knowledge
The Knowledge Framework owns the responsibility for preservation. The Knowledge Repository is the persistent representation and maintained project home of Accepted Knowledge. It can preserve accepted findings, qualifications, uncertainty, source records, terminology, procedures, standards, decisions, examples, and other reusable project intelligence.
Knowledge responsibility: preserve what the project is prepared to rely upon, with enough structure and status to distinguish it from unresolved, excluded, superseded, or provisional material.
Step 5: Runtime Uses Approved Knowledge for the Current Task
Runtime answers a different question: what must the system do now? A Runtime Request defines the current objective, supplies the complete relevant approved Knowledge, applies current variables and Governance, states the task, and defines the required Project Output.
Critical rule: Runtime uses approved Knowledge without quietly reopening Research or changing the maintained Knowledge Repository.
Step 6: AI Performs the Current Execution
The AI uses the Runtime Request, the accessible approved Knowledge, and the applicable Governance to perform the defined task. Runtime may create, transform, analyze, compare, organize, calculate, draft, or otherwise execute the work described by the request.
AI responsibility: execute within the supplied structure and expose missing required information rather than silently inventing project facts or treating inaccessible material as if it had been read.
Step 7: Project Output Returns to Human Review
The result of Runtime is a Project Output: a document, analysis, plan, presentation, media asset, software component, lesson, or other deliverable. A Project Output is the visible result of the system's operation; it is not a fifth DCPF framework.
Human responsibility: review the output against the task, approved Knowledge, applicable Governance, and human expectations before deciding whether to accept, revise, reject, escalate, or use it.
Human Decisions Are the Handoffs
The arrows in a DCPF workflow do not mean that information automatically passes from one AI step to another. They represent a change in responsibility, and the important changes in status remain subject to human direction.
- People define what the project is trying to accomplish and which standards apply.
- People decide what Research evidence is accepted, revised, excluded, or returned for additional investigation.
- People determine what becomes Accepted Knowledge and what remains unresolved or provisional.
- People decide what approved Knowledge is relevant to the current Runtime task.
- People decide whether a Project Output is acceptable and appropriate to use.
- People authorize changes to maintained Knowledge or Governance rather than allowing an AI suggestion to become authoritative by itself.
Human direction establishes purpose and standards. External architecture preserves the project foundation. AI reasoning performs Research and Runtime work within the context and authority it has actually been given.
The AI Must Be Able to Access the Material It Is Supposed to Use
DCPF distinguishes identifying an artifact from supplying its contents. An AI system cannot reliably use information it cannot access. A filename, artifact ID, prior-chat reference, folder location, or link label does not by itself provide the content.
Embed or paste it
Place the complete required content inside the current request, artifact, or working context.
Retrieve it from an accessible source
Use a connected repository, file system, database, website, or other source only when the AI can actually retrieve and read the required content.
When Runtime depends on maintained Knowledge, the AI must receive or retrieve the approved content itself, not merely its name.
The Knowledge Handoff Preserves More Than Conclusions
When accepted Research moves into the Knowledge Repository, DCPF does not require the project to throw away the useful structure of the reviewed Research Output and replace it with an improvised summary.
Preserve accepted findings, qualifications, uncertainty, useful detail, and source records when they remain relevant. Separate unresolved, excluded, superseded, or provisional material as Governance requires. Maintain changes through versioning and review rather than silently overwriting the project's official Knowledge.
Research develops evidence. Human review changes its status. Knowledge preserves what has been accepted.
DCPF Is Sequential, but It Is Not One-Way
The core workflow is sequential where responsibility changes: Research develops evidence before accepted Research-derived Knowledge is preserved, and Runtime uses approved Knowledge before producing a Project Output. But sustained work is also iterative. A gap or failure should return to the framework that owns the missing or incorrect responsibility.
Missing or insufficient evidence
Return to Research.
Accepted Knowledge is outdated, incomplete, or incorrectly maintained
Return to the Knowledge responsibility and repository maintenance process.
The correct Knowledge exists but the task, variables, instructions, or output requirements are wrong
Correct Runtime.
A recurring source, quality, safety, approval, or boundary problem exists across work
Correct Governance.
The current output itself needs a one-time revision but the underlying architecture is sound
Revise the Project Output without unnecessarily changing the maintained frameworks.
Preserve reusable improvements in the framework that owns them instead of patching every future prompt.
One Knowledge Foundation Can Support Many Runtime Tasks
The separation between Knowledge and Runtime allows one maintained body of Accepted Knowledge to support many different activities. The project does not have to rebuild its approved foundation each time it asks the AI to perform a new task.
A single Knowledge Repository might support different audiences, formats, analyses, transformations, or deliverables. Runtime changes the current use while the approved Knowledge remains maintained separately.
Knowledge supplies the foundation. Runtime determines the current use.
A Complete Small DCPF Cycle
A first low-risk project does not require four standalone framework documents. Minimum Viable DCPF keeps all four framework responsibilities visible while using the smallest artifact structure that makes the work inspectable.
A small cycle can use a Research Request with the applicable Governance controls embedded in it; human review of the Research Output; preservation of Accepted Knowledge in a Knowledge Repository; a Runtime Request with the applicable Governance controls and complete approved Knowledge; and human review of the resulting Project Output.
As recurring controls emerge, preserve them in the Governance Repository. The Repository supports consistency, reuse, versioning, and oversight, but it is not an execution dependency for Research, Knowledge, or Runtime.
How DCPF Works in One View
- Humans define purpose, standards, boundaries, and decision rights.
- A Research Request directs an authorized investigation.
- AI Research produces a Research Output containing evidence for review.
- Research Output does not automatically become Knowledge.
- Human review determines what information becomes Accepted Knowledge.
- The Knowledge Repository preserves Accepted Knowledge and its useful qualifications, sources, and status.
- A Runtime Request supplies the current task, variables, the applicable Governance controls stated within the request, and the complete approved Knowledge required for execution.
- AI Runtime produces a Project Output without silently changing the maintained repository.
- Humans review the Project Output and decide whether to accept, revise, reject, escalate, or use it.
- Gaps return to the DCPF responsibility that owns the problem.
- Governance remains active across the entire workflow.
Where to Go Next
You now have the complete operating relationship. The next learning step is to examine each framework in depth: what responsibility it owns, why that responsibility matters, which standard responsibilities should remain explicit, what happens when those responsibilities are undefined, and how the framework is represented in practical artifacts.