570 lines
11 KiB
Markdown
570 lines
11 KiB
Markdown
# Depth vs Automation Rules
|
|
|
|
## 1. Purpose
|
|
|
|
This file defines how CCPE Forge should distinguish depth-oriented work from automation-oriented work.
|
|
|
|
This distinction is essential because not every Agentic system should become more autonomous.
|
|
|
|
Some systems exist to deepen thinking.
|
|
|
|
Some exist to automate execution.
|
|
|
|
Many of the user's most valuable workflows are hybrid: human-led depth with automated support.
|
|
|
|
This distinction also decides repository ownership. Depth and cognitive architecture usually belong in CCPE or project discussions. Deterministic automation implementation belongs in `skills-vault`. Concrete project execution records belong in the project repository.
|
|
|
|
## 2. Core Distinction
|
|
|
|
The key distinction is:
|
|
|
|
```text
|
|
Depth-Oriented:
|
|
The main value comes from judgment, interpretation, model-building, critique, and conceptual depth.
|
|
|
|
Automation-Oriented:
|
|
The main value comes from executing stable, repeatable, verifiable procedures.
|
|
|
|
Hybrid:
|
|
The main value comes from human-led depth, while automation supports routing, collection, formatting, indexing, or implementation.
|
|
```
|
|
|
|
## 3. Depth-Oriented Work
|
|
|
|
### 3.1 Definition
|
|
|
|
Depth-Oriented work is work where the central task is cognitive, interpretive, theoretical, creative, strategic, or evaluative.
|
|
|
|
The AI system should support human thought, not replace it.
|
|
|
|
### 3.2 Common Examples
|
|
|
|
```text
|
|
Conceptual modeling
|
|
Theoretical writing
|
|
Article planning
|
|
Essay critique
|
|
Argument stress-testing
|
|
Socratic questioning
|
|
Cognitive model extraction
|
|
Strategic reflection
|
|
Original framework design
|
|
Review of user-authored models
|
|
High-uncertainty research synthesis
|
|
```
|
|
|
|
Deep creation, such as article premise formation, outline judgment, and authorial decision-making, is Depth-Oriented unless a concrete project requirement proves that a smaller operational piece is stable enough to automate.
|
|
|
|
### 3.3 Typical Artifact Types
|
|
|
|
Depth-Oriented work often uses:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
Model Card
|
|
Model Mining
|
|
Interactive Runtime
|
|
Workshop Mode
|
|
```
|
|
|
|
### 3.4 Characteristics
|
|
|
|
Depth-Oriented work usually has:
|
|
|
|
```text
|
|
High ambiguity
|
|
High interpretive load
|
|
High model dependence
|
|
High user authorship
|
|
High uncertainty
|
|
Weak external validation
|
|
Need for iteration
|
|
Need for human decision
|
|
Need for preserving conceptual flavor
|
|
```
|
|
|
|
### 3.5 Design Requirements
|
|
|
|
Depth-Oriented artifacts should include:
|
|
|
|
```text
|
|
Human decision gates
|
|
Reasoning summaries
|
|
Uncertainty notes
|
|
Model fidelity checks
|
|
Scope boundaries
|
|
Failure modes
|
|
Follow-up discussion mode
|
|
Versioned decisions if long-running
|
|
```
|
|
|
|
### 3.6 What to Avoid
|
|
|
|
Avoid:
|
|
|
|
```text
|
|
Full automation
|
|
Premature closure
|
|
Generic summarization
|
|
Flattening metaphors
|
|
Replacing human judgment
|
|
Overconfident synthesis
|
|
Unapproved model promotion
|
|
```
|
|
|
|
## 4. Automation-Oriented Work
|
|
|
|
### 4.1 Definition
|
|
|
|
Automation-Oriented work is work where the central task is execution of stable procedures.
|
|
|
|
The AI system should reduce repetitive labor while preserving safety and validation.
|
|
|
|
### 4.2 Common Examples
|
|
|
|
```text
|
|
Format conversion
|
|
File organization
|
|
Batch report collection
|
|
Voice-to-text preprocessing
|
|
Template generation
|
|
Index draft update
|
|
Low-risk code changes
|
|
Data extraction
|
|
Archive update
|
|
Report deduplication
|
|
```
|
|
|
|
### 4.3 Typical Artifact Types
|
|
|
|
Automation-Oriented work often uses:
|
|
|
|
```text
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Tool Skill
|
|
Workflow Skill
|
|
Evaluation Skill
|
|
Automation Runtime
|
|
```
|
|
|
|
### 4.4 Characteristics
|
|
|
|
Automation-Oriented work usually has:
|
|
|
|
```text
|
|
Stable steps
|
|
Clear input/output
|
|
Low ambiguity
|
|
Observable success criteria
|
|
Tool or file operations
|
|
Repeatability
|
|
Validation method
|
|
Failure handling
|
|
```
|
|
|
|
### 4.5 Design Requirements
|
|
|
|
Automation-Oriented artifacts should include:
|
|
|
|
```text
|
|
Tool scope
|
|
Allowed actions
|
|
Actions requiring confirmation
|
|
Forbidden actions
|
|
Validation method
|
|
Error handling
|
|
Rollback or recovery
|
|
Logging
|
|
State handling
|
|
```
|
|
|
|
### 4.6 What to Avoid
|
|
|
|
Avoid:
|
|
|
|
```text
|
|
Vague authority
|
|
Unvalidated file writes
|
|
Unapproved external actions
|
|
Automation of high-uncertainty judgment
|
|
Silent canonical updates
|
|
No rollback path
|
|
```
|
|
|
|
## 5. Hybrid Work
|
|
|
|
### 5.1 Definition
|
|
|
|
Hybrid work combines deep human-led cognition with automated support.
|
|
|
|
The core judgment remains human-led.
|
|
|
|
The surrounding process may be assisted or partially automated.
|
|
|
|
### 5.2 Common Examples
|
|
|
|
```text
|
|
Review committee
|
|
Modeling committee
|
|
Article-to-model extraction pipeline
|
|
Agent upgrade workflow
|
|
Writing pipeline
|
|
Coding project after plan approval
|
|
Knowledge library maintenance
|
|
```
|
|
|
|
### 5.3 Typical Artifact Types
|
|
|
|
Hybrid work often uses:
|
|
|
|
```text
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Model Card
|
|
Model Index
|
|
Hybrid Runtime
|
|
Workshop Mode
|
|
```
|
|
|
|
### 5.4 Characteristics
|
|
|
|
Hybrid work usually has:
|
|
|
|
```text
|
|
Human-led conceptual direction
|
|
Agent-assisted critique or extraction
|
|
Automated collection
|
|
Automated deduplication
|
|
Automated formatting
|
|
Human approval for canonical changes
|
|
State tracking
|
|
Versioning
|
|
```
|
|
|
|
### 5.5 Design Requirements
|
|
|
|
Hybrid artifacts should explicitly separate:
|
|
|
|
```text
|
|
Human-led reasoning
|
|
Agent-assisted analysis
|
|
Automated support operations
|
|
Human approval gates
|
|
Canonical update rules
|
|
```
|
|
|
|
## 6. Decision Questions
|
|
|
|
Use these questions to classify depth vs automation:
|
|
|
|
```text
|
|
Does the task require original judgment?
|
|
Does the output affect the user's conceptual framework?
|
|
Can success be easily validated?
|
|
Are there stable repeatable steps?
|
|
Would automation reduce quality?
|
|
Would manual work be repetitive without adding judgment?
|
|
Are tools or files involved?
|
|
Is human approval required before finalization?
|
|
Does the work involve model authorship?
|
|
Does the work involve canonical knowledge changes?
|
|
```
|
|
|
|
## 7. Classification Rules
|
|
|
|
### 7.1 Use Depth-Oriented When
|
|
|
|
```text
|
|
Human interpretation is central.
|
|
The task is conceptually ambiguous.
|
|
The work involves original models.
|
|
The output requires taste or judgment.
|
|
The system is a thinking partner.
|
|
The artifact critiques, questions, or reframes.
|
|
```
|
|
|
|
### 7.2 Use Automation-Oriented When
|
|
|
|
```text
|
|
The steps are stable.
|
|
The output is objectively checkable.
|
|
The task is repetitive.
|
|
The process uses tools or files.
|
|
The risk is low or controllable.
|
|
The user wants execution efficiency.
|
|
```
|
|
|
|
### 7.3 Use Hybrid When
|
|
|
|
```text
|
|
Human judgment is central, but support work is repetitive.
|
|
Multiple agents produce reports.
|
|
Reports need collection and synthesis.
|
|
Models need extraction and indexing.
|
|
Code implementation follows human-approved plans.
|
|
Canonical outputs require human approval.
|
|
```
|
|
|
|
## 8. Human Decision Gates
|
|
|
|
Human decision gates are required for Depth-Oriented and Hybrid work when:
|
|
|
|
```text
|
|
A model is named or renamed.
|
|
A model is promoted to active.
|
|
A major agent is split.
|
|
A Runtime is created.
|
|
A conceptual conclusion is adopted.
|
|
A synthesis resolves conflicting reports.
|
|
A file becomes canonical.
|
|
A workflow becomes automated.
|
|
```
|
|
|
|
## 9. Automation Boundary
|
|
|
|
For any Automation-Oriented or Hybrid artifact, define:
|
|
|
|
```text
|
|
Allowed automated actions
|
|
Actions requiring confirmation
|
|
Forbidden actions
|
|
Validation method
|
|
Failure handling
|
|
Rollback or recovery
|
|
Logging / trace
|
|
```
|
|
|
|
## 10. Example: Review Committee
|
|
|
|
Classification:
|
|
|
|
```text
|
|
Hybrid
|
|
```
|
|
|
|
Depth part:
|
|
|
|
```text
|
|
Human decides topic, evaluates reports, chooses revisions.
|
|
Agents provide critique from different perspectives.
|
|
```
|
|
|
|
Automation part:
|
|
|
|
```text
|
|
Invoke multiple reviewers.
|
|
Collect reports.
|
|
Deduplicate repeated issues.
|
|
Cluster findings.
|
|
Generate synthesis draft.
|
|
Archive outputs.
|
|
```
|
|
|
|
Human gates:
|
|
|
|
```text
|
|
Approve synthesis.
|
|
Choose which critique to accept.
|
|
Decide final revision direction.
|
|
Promote any derived model or insight.
|
|
```
|
|
|
|
## 11. Example: Cognitive Imaging Specialist
|
|
|
|
Classification:
|
|
|
|
```text
|
|
Depth-Oriented in Expert Mode
|
|
Hybrid if used inside automated review collection
|
|
```
|
|
|
|
Depth part:
|
|
|
|
```text
|
|
Identifies prediction error, causal generator, falsification boundary.
|
|
```
|
|
|
|
Potential automation:
|
|
|
|
```text
|
|
Format report.
|
|
Run as one of several reviewers.
|
|
Send report to synthesis agent.
|
|
Archive report.
|
|
```
|
|
|
|
Human gates:
|
|
|
|
```text
|
|
Accept or reject the insight.
|
|
Decide whether extracted model should be updated.
|
|
Decide whether the report changes the article direction.
|
|
```
|
|
|
|
## 12. Example: Model Mining from Essays
|
|
|
|
Classification:
|
|
|
|
```text
|
|
Hybrid
|
|
```
|
|
|
|
Depth part:
|
|
|
|
```text
|
|
Determining whether an idea is truly a model.
|
|
Preserving conceptual flavor.
|
|
Confirming model scope and name.
|
|
```
|
|
|
|
Automation part:
|
|
|
|
```text
|
|
Draft candidate Model Cards.
|
|
Suggest Model Index entries.
|
|
Detect related models.
|
|
Prepare extraction log.
|
|
```
|
|
|
|
Human gates:
|
|
|
|
```text
|
|
Confirm model identity.
|
|
Confirm status.
|
|
Promote to active.
|
|
Merge or reject candidates.
|
|
```
|
|
|
|
## 13. Example: Coding Project
|
|
|
|
Planning stage:
|
|
|
|
```text
|
|
Depth-Oriented or Workshop Mode
|
|
```
|
|
|
|
Implementation stage after plan approval:
|
|
|
|
```text
|
|
Automation-Oriented or Hybrid
|
|
```
|
|
|
|
Rules:
|
|
|
|
```text
|
|
Do not automate architecture before agreement.
|
|
Do not implement before requirements are clear.
|
|
After plan approval, automation can handle code edits, tests, and documentation within defined boundaries.
|
|
```
|
|
|
|
## 14. Risk Levels
|
|
|
|
Use these risk levels:
|
|
|
|
```text
|
|
Low:
|
|
Formatting, draft generation, non-canonical notes.
|
|
|
|
Medium:
|
|
Creating draft Model Cards, modifying non-canonical artifacts, generating Skill drafts.
|
|
|
|
High:
|
|
Changing canonical model definitions, modifying active agents, creating Runtime automation.
|
|
|
|
Critical:
|
|
Deleting files, executing external actions, publishing, irreversible code or data changes.
|
|
```
|
|
|
|
## 15. Risk Handling
|
|
|
|
For Low risk:
|
|
|
|
```text
|
|
Proceed with normal validation.
|
|
```
|
|
|
|
For Medium risk:
|
|
|
|
```text
|
|
State assumptions and provide review checklist.
|
|
```
|
|
|
|
For High risk:
|
|
|
|
```text
|
|
Require human confirmation.
|
|
Create draft first.
|
|
Preserve original.
|
|
```
|
|
|
|
For Critical risk:
|
|
|
|
```text
|
|
Require explicit approval.
|
|
Provide rollback or recovery plan.
|
|
Do not proceed silently.
|
|
```
|
|
|
|
## 16. Depth Preservation Checklist
|
|
|
|
For Depth-Oriented work, check:
|
|
|
|
```text
|
|
Did we preserve the user's model?
|
|
Did we preserve the conceptual tension?
|
|
Did we avoid generic summary?
|
|
Did we mark uncertainty?
|
|
Did we keep human judgment central?
|
|
Did we define where the model fails?
|
|
Did we avoid over-automation?
|
|
```
|
|
|
|
## 17. Automation Safety Checklist
|
|
|
|
For Automation-Oriented work, check:
|
|
|
|
```text
|
|
Are allowed actions clear?
|
|
Are forbidden actions clear?
|
|
Is validation defined?
|
|
Is failure handling defined?
|
|
Is rollback possible?
|
|
Are file operations safe?
|
|
Are human confirmations required where needed?
|
|
```
|
|
|
|
## 18. Hybrid Design Checklist
|
|
|
|
For Hybrid work, check:
|
|
|
|
```text
|
|
Is the human-led part explicit?
|
|
Is the automated support part explicit?
|
|
Are decision gates marked?
|
|
Are canonical updates protected?
|
|
Is state tracked?
|
|
Are outputs reviewable?
|
|
```
|
|
|
|
## 19. Final Rule
|
|
|
|
Do not ask:
|
|
|
|
```text
|
|
How can we automate this?
|
|
```
|
|
|
|
Ask first:
|
|
|
|
```text
|
|
Where is human judgment essential?
|
|
Where is repeated labor wasting time?
|
|
Where can automation support without damaging depth?
|
|
```
|
|
|
|
The right design preserves depth and automates friction.
|
|
|