ccpe-system/.codex/skills/ccpe-forge/references/depth-vs-automation-rules.md

10 KiB

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.

2. Core Distinction

The key distinction is:

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

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

3.3 Typical Artifact Types

Depth-Oriented work often uses:

CCPE-Lite
CCPE-Agent
Model Card
Model Mining
Interactive Runtime
Workshop Mode

3.4 Characteristics

Depth-Oriented work usually has:

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:

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:

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

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:

CCPE-Skill
CCPE-Runtime
Tool Skill
Workflow Skill
Evaluation Skill
Automation Runtime

4.4 Characteristics

Automation-Oriented work usually has:

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:

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:

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

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:

CCPE-Agent
CCPE-Skill
CCPE-Runtime
Model Card
Model Index
Hybrid Runtime
Workshop Mode

5.4 Characteristics

Hybrid work usually has:

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:

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:

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

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

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

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:

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:

Allowed automated actions
Actions requiring confirmation
Forbidden actions
Validation method
Failure handling
Rollback or recovery
Logging / trace

10. Example: Review Committee

Classification:

Hybrid

Depth part:

Human decides topic, evaluates reports, chooses revisions.
Agents provide critique from different perspectives.

Automation part:

Invoke multiple reviewers.
Collect reports.
Deduplicate repeated issues.
Cluster findings.
Generate synthesis draft.
Archive outputs.

Human gates:

Approve synthesis.
Choose which critique to accept.
Decide final revision direction.
Promote any derived model or insight.

11. Example: Cognitive Imaging Specialist

Classification:

Depth-Oriented in Expert Mode
Hybrid if used inside automated review collection

Depth part:

Identifies prediction error, causal generator, falsification boundary.

Potential automation:

Format report.
Run as one of several reviewers.
Send report to synthesis agent.
Archive report.

Human gates:

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:

Hybrid

Depth part:

Determining whether an idea is truly a model.
Preserving conceptual flavor.
Confirming model scope and name.

Automation part:

Draft candidate Model Cards.
Suggest Model Index entries.
Detect related models.
Prepare extraction log.

Human gates:

Confirm model identity.
Confirm status.
Promote to active.
Merge or reject candidates.

13. Example: Coding Project

Planning stage:

Depth-Oriented or Workshop Mode

Implementation stage after plan approval:

Automation-Oriented or Hybrid

Rules:

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:

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:

Proceed with normal validation.

For Medium risk:

State assumptions and provide review checklist.

For High risk:

Require human confirmation.
Create draft first.
Preserve original.

For Critical risk:

Require explicit approval.
Provide rollback or recovery plan.
Do not proceed silently.

16. Depth Preservation Checklist

For Depth-Oriented work, check:

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:

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:

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:

How can we automate this?

Ask first:

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.