Attach It
Upload the required document or source directly into the AI interaction.
Start Using DCPF
Build the smallest controlled implementation that preserves the responsibilities your work needs.
Start With the Smallest Useful Implementation
You do not need a large system. A first DCPF implementation can use ordinary documents, a simple project folder, and an AI model that can read the materials you supply.
Begin with one controlled, low-risk project in a domain you understand. Make the responsibilities explicit enough to inspect, test, review, and reuse. Add structure only when the work creates a reason for it.
Start small. Preserve the responsibilities. Test the implementation. Let the project earn additional complexity.
DCPF is experimental.
Use this page to build a test implementation, not to treat DCPF as a guarantee of accuracy, safety, compliance, or suitability. Validate the project, artifacts, AI behavior, evidence controls, handoffs, and review process in your own environment before considering consequential or production use.
The Website Is Your DCPF and AI Starter Kit
The learning pages explain the architecture, and this page provides the practical setup path and condensed starter artifacts for a first implementation. You do not need a separate starter package before beginning.
A browsing-capable AI can use these official pages while helping you customize a project. The complete Introductory Edition provides deeper explanations, full templates, practicums, appendices, and supporting guidance.
What You Need
- An AI system capable of reading the information and artifacts you provide
- A word processor, text editor, or other way to maintain project artifacts
- A simple folder or maintained location for project files
- A low-risk project whose purpose and results you can evaluate
- A human review plan for Research, Accepted Knowledge, Runtime Requests, and Project Outputs
Specialized software, databases, automation, agents, or enterprise infrastructure are not prerequisites.
Create a Simple Working Environment
DCPF Projects
└── Project Name
├── Frozen Frameworks
├── Working Artifacts
├── Research Outputs
├── Knowledge Repository
├── Project Outputs
└── Archive
- Frozen Frameworks: clean starter files.
- Working Artifacts: project-specific requests and artifacts being developed or tested.
- Research Outputs: evidence products returned by Research.
- Knowledge Repository: information reviewed and accepted for reuse.
- Project Outputs: deliverables produced by Runtime.
- Archive: older, superseded, or retired versions when history matters.
Keep the instruction, the AI result, and the information later approved as Knowledge from becoming mixed together.
The Minimum Viable DCPF Cycle
- Create a Research Request containing the Governance controls needed for the investigation.
- Run the Research, review the Research Output, and decide what information is accepted.
- Preserve Accepted Knowledge in a Knowledge Repository.
- Create a Runtime Request containing the approved Knowledge and applicable Governance.
- Review the Project Output and decide whether to accept, revise, reject, escalate, use, preserve, or route a gap back to its owning framework.
This is a complete cycle even when Governance is embedded in working artifacts rather than maintained as a separate document.
A Simple Workflow for Every Starter Artifact
- Make a working copy and preserve the clean master.
- Replace bracketed instructions with your project decisions. AI may interview you and draft wording, but you review and approve the decisions.
- Save the completed working copy as DRAFT or TEST before execution.
- Give the complete artifact to AI by attaching it, embedding or pasting it, or retrieving it from a source the AI can actually read.
- Explicitly tell the AI to execute the artifact.
- Save the AI result separately from the request.
- Review the result against the request, Knowledge, Governance, evidence, and project success criteria.
- Revise the responsibility that owns any problem and repeat the appropriate step.
- Move information or artifacts into an accepted state only after human review.
Starter 1: Embedded Governance Controls
EMBEDDED GOVERNANCE CONTROLS - WORKING COPY
Project / Scope: [Identify what these controls govern.]
1. Framework Purpose
[State what the controls govern and where their authority applies.]
2. Quality Standards
[Define observable conditions satisfactory work must meet.]
3. Approved Information Sources
[Identify permitted evidence, data, Knowledge, or inputs.]
4. Prohibited Content
[Identify prohibited sources, actions, content, or substitutions.]
5. Validation Requirements
[State required checks, reviews, decision states, and approvals.]
6. Output Standards
[State recurring organization, citation, format, accessibility, sequence, disclosure, or completion requirements.]
7. Revision History
[Record version or date, relevant changes, and approving human authority.]
Human Authority / Escalation:
[Identify who reviews, approves, or resolves conflicts and exceptions.]
What You Do With It
Fill it in first, then place the applicable controls inside the Research or Runtime Request. Review the decisions yourself and save the combined artifact in Working Artifacts. For a first project, you normally do not run this block as a separate task. Consolidate recurring controls later when a maintained Governance artifact improves consistency or oversight.
Starter 2: Research Request
RESEARCH REQUEST - WORKING COPY
Identity
Project: [Project name]
Owner: [Responsible person or role]
Version / Status: [Version and DRAFT or TEST]
Framework Purpose: [Why this Research is needed and its intended use.]
Research Configuration Variables: [Subject, place, period, audience, depth, jurisdiction, version, or current values.]
Research Objectives: [Questions, comparisons, and required topics.]
Research Scope: [Inclusions, exclusions, depth, recency, and stopping boundaries.]
Approved Information Sources: [Permitted source categories or exact sources.]
Source Priority Hierarchy: [How evidence is weighed and conflicts handled.]
Output Organization: [Required Research Output structure.]
Research Source Documentation: [Source details that must be preserved.]
Sequential Output Requirements: [Continuation behavior when needed.]
Governance References: [Embed applicable controls or identify an exact artifact and version the AI can access.]
What You Do With It
Fill and review every section, save the request in Working Artifacts, supply the complete file to AI, and say, “Execute this Research Request.” Save the result in Research Outputs. Check objective coverage, scope, approved sources, source priority, citations, uncertainty, conflicts, unsupported claims, and Governance before accepting anything into Knowledge.
Starter 3: Knowledge Repository
KNOWLEDGE REPOSITORY - WORKING COPY
1. Framework Purpose
[State what Accepted Knowledge is preserved, why, and for what reuse.]
2. Knowledge Configuration Variables
[Current subject, category, view, selection, audience, version, or use condition.]
3. Knowledge Structure
[Place human-reviewed Accepted Knowledge here with qualifications, uncertainty, source context, and use limits.]
4. Information Categories
[Use headings, labels, classifications, or status groupings.]
5. Governance References
[Controls for admission, status, maintenance, protection, revision, removal, and use.]
Optional Metadata
[Version, date, status, owner, tags, sources, review date, scope, or related entries when useful.]
What You Do With It
After reviewing Research, preserve only accepted material. Keep unresolved, rejected, outdated, superseded, or provisional information separate. Review and approve the Repository for a defined scope. When Runtime needs it, supply the actual approved content, not merely its filename or identifier.
Starter 4: Runtime Request
RUNTIME REQUEST - WORKING COPY
Identity
Project: [Project name]
Owner: [Responsible person or role]
Version / Status: [Version and DRAFT or TEST]
Framework Purpose: [What Runtime must perform now and why.]
Runtime Configuration Variables: [Audience, subject, length, tone, format, technical level, delivery setting, or current values.]
Input Knowledge
[Supply the complete approved Knowledge or an exact retrieval instruction to a source the AI can access.]
Task Definition: [Exactly what the AI must do.]
Output Requirements: [Required form, organization, components, limits, validation notes, and completion conditions.]
Sequential Output Requirements: [Continuation behavior when needed.]
Governance References: [Embed applicable controls or identify an exact accessible artifact and version.]
What You Do With It
Complete and save the request in Working Artifacts. Supply all required Knowledge and Governance, then say, “Execute this Runtime Request using only the supplied or authorized Knowledge and Governance.” Save the result in Project Outputs. Review the task, output requirements, Knowledge use, unsupported claims, Governance, completeness, and success criteria before accepting or using it.
Make Sure the AI Can Actually Access Every Artifact
Embed or Paste It
Place the complete required content inside the current request or working context.
Retrieve It
Use a connected repository, file system, database, website, or other source only when the AI can actually retrieve and read the content.
A filename, artifact ID, prior-chat reference, folder location, or link label is not the same as supplying the content.
Use a Test-and-Approval Lifecycle
Clean Master → Working Copy → Draft → Small Test → Evaluate → Revise and Retest → Approve
Compare results with explicit success criteria. A polished answer is not the same as a validated implementation. A project-specific artifact becomes authoritative only after the designated human authority approves a tested version for a defined scope.
When Something Goes Wrong, Fix the Responsibility That Owns It
- Missing evidence: return to Research.
- Outdated, incorrect, or incomplete Accepted Knowledge: use the Research and Knowledge maintenance process.
- Wrong audience, task, format, length, or deliverable: revise Runtime.
- Missing recurring source, quality, safety, validation, output, or approval rule: revise Governance through human review.
- The correct artifact was named but not supplied: correct artifact access before changing the framework.
Revise the responsibility that owns the problem instead of patching every future prompt.
Two Quick Checks
Before Execution
Do I have the correct framework, the complete required content, the applicable Governance, a clear definition of completion, and a human review plan?
After Execution
Should this result be accepted, revised, rejected, escalated, preserved, or routed back to the framework that owns the discovered gap?
Where to Go Next
You now have the practical path and compact artifacts for a first Minimum Viable DCPF implementation.