1. Input Knowledge
The complete relevant approved Knowledge the AI needs to perform the task correctly.
Runtime Framework
Using approved Knowledge and current instructions to perform a defined task.
What Is the Runtime Framework?
The DCPF Runtime Framework directs execution. It defines what the AI must do now, supplies the approved Knowledge needed for that task, applies current variables and Governance controls, and establishes the required Project Output.
Runtime does not own the project’s maintained Knowledge and does not quietly reopen Research. It performs authorized work from the complete context it has actually been given, then returns the result for human review.
Knowledge supplies the approved foundation. Runtime directs the current execution.
DCPF is experimental.
DCPF has demonstrated promise through development work, practical applications, and training practicums, but it has not been broadly or independently validated. Begin with controlled, low-risk Runtime tasks, validate the approach for your domain and AI environment, independently verify consequential outputs, and retain human authority over acceptance and use.
The Three-Component Execution Model
A Runtime execution combines three distinct components:
2. Runtime Request
The current objective, variables, workflow, controls, boundaries, task, and output requirements.
3. Project Output
The document, analysis, plan, code, media asset, or other deliverable produced by the execution.
The Project Output is the result of Runtime, not a fifth DCPF framework. It remains subject to human review before acceptance or use.
The Seven Standard Runtime Responsibilities
Every Runtime artifact should address seven standard responsibilities. Their detail should be proportionate to the task’s risk, complexity, and consequences.
1. Runtime Objective
State the immediate purpose of the execution and the outcome it is intended to support.
Teaching question: What must this execution accomplish now?
2. Input Knowledge
Identify and supply the complete approved Knowledge required for the task, including applicable qualifications and constraints.
Teaching question: Which Accepted Knowledge must the AI actually have access to before it begins?
3. Current Variables and Inputs
Provide the case-specific facts, selections, parameters, files, user inputs, and current conditions that distinguish this execution from another.
Teaching question: What is true or selected for this particular run?
4. Task Definition
Define the work the AI must perform, including the required reasoning, transformation, comparison, creation, or other action.
Teaching question: What must the AI do with the supplied Knowledge and current inputs?
5. Execution Process
Specify the workflow, order of operations, checkpoints, tool use, interactions, and any Sequential Output Requirements.
Teaching question: How must the work proceed, and where must the AI pause or obtain permission?
6. Output Requirements
Define the required deliverable, structure, format, coverage, quality, accessibility, file type, and completion conditions.
Teaching question: What must the finished Project Output contain and look like?
7. Authority, Boundaries, and Failure Handling
State what the AI may decide, what requires human authority, which actions are prohibited, and what to do when required information or capability is missing.
Teaching question: When must the AI stop, disclose a limitation, or return control to a person?
Task Definition and Output Requirements Are Different
Task Definition describes the work to perform: analyze, compare, draft, calculate, transform, organize, or create. Output Requirements describe the deliverable that must result: its sections, format, length, contents, file type, accessibility, quality criteria, and completion conditions.
Keeping them separate prevents a clear activity from producing the wrong deliverable and prevents a clear format from hiding an undefined task.
Sequential Output Requirements
Some work should be delivered in controlled segments rather than one uninterrupted response. Sequential Output Requirements, or SORs, define those segments, their order, and the points where the AI must pause.
Complete the current required output segment, then stop and wait for explicit permission before continuing to the next segment.
SORs can support review, accessibility, long-form work, resource limits, and deliberate human decision points. Natural breaks may be used when appropriate, but the AI should not treat silence, an unrelated message, or completion of one segment as permission to continue.
Runtime Must Have Actual Access to Its Inputs
The executing AI must receive or have verified access to the complete approved Knowledge, Runtime Request, current variables, and files required for the task. Naming a document, providing an inaccessible link, or referring to another conversation does not make that material available.
If a required input is missing, unreadable, incomplete, or contradictory, the AI should identify the problem and stop or request clarification according to the Runtime authority rules. It should not invent project facts, pretend to have read unavailable material, or silently substitute new Research.
AI Authority and Human Authority
Within the Runtime Request, AI may reason, draft, compare, organize, calculate, transform, and use authorized tools as directed. Its authority is bounded by the supplied Knowledge, applicable Governance, current task, and explicit permissions.
AI does not independently expand project scope, approve its own output, change maintained Knowledge, establish new Governance, decide that missing information is unimportant, or convert a suggestion into an authoritative project decision.
People decide whether the Project Output meets the task and applicable standards, whether it is appropriate to use, and whether any result should trigger a change elsewhere in the DCPF system.
A Project Output Does Not Automatically Become Knowledge
A successful Runtime execution produces a Project Output. That output may be useful, accurate, and approved for its immediate purpose without becoming reusable Accepted Knowledge.
If part of an output should become maintained Knowledge, route it through the applicable human review and Knowledge acceptance process. This prevents generated content, temporary calculations, case-specific assumptions, or unverified statements from quietly entering the project foundation.
Route Feedback to the Responsibility That Owns It
- Missing or uncertain information: return the need to Research.
- Outdated, incomplete, or poorly organized Accepted Knowledge: return it to the Knowledge Framework and Repository.
- Unclear tasks, inputs, workflow, or output requirements: revise the Runtime artifact.
- Recurring standards, authority, boundary, or review problems: refine Governance and preserve recurring controls when appropriate.
Runtime reveals problems, but it should not silently assume ownership of responsibilities that belong elsewhere.
When a Runtime Responsibility Is Left Undefined
An undefined objective can produce irrelevant work. Missing Knowledge can invite invented facts or hallucinations. Unclear current inputs can lead the AI to assume the wrong case. A vague task can produce the wrong action. An undefined process can skip necessary review points. Missing output requirements can create an unusable deliverable. Unclear authority can allow the AI to continue when it should stop.
Making all seven responsibilities explicit does not guarantee a correct result, but it exposes the conditions people need to inspect, test, and improve.
Where to Go Next
The four DCPF framework pages now explain the complete architecture. Continue to the practical guidance to decide how much structure your work needs and begin using DCPF.