ccpe-system/runtimes

Runtimes

1. Purpose

This directory stores CCPE Runtime Specs.

A Runtime defines how a workflow operates across stages, agents, skills, tools, state, and human decision gates.

Runtime does not automatically mean full automation.

2. Directory Structure

Recommended subdirectories:

runtimes/
├── interactive/
├── automation/
└── hybrid/

3. Runtime Types

3.1 interactive/

Use for human-led, multi-stage cognitive work.

Examples:

modeling-committee.runtime.md
deep-writing-workshop.runtime.md
theory-refinement.runtime.md

Interactive Runtime is suitable when:

Human judgment is central.
Work is high-uncertainty.
Multiple agents assist but do not replace decision-making.
The process has stages and handoffs.

3.2 automation/

Use for stable, repeatable, verifiable workflows.

Examples:

batch-agent-upgrade.runtime.md
format-conversion.runtime.md
index-update.runtime.md

Automation Runtime is suitable when:

Steps are stable.
Outputs are checkable.
Risk is bounded.
Tools or files are involved.
Validation and recovery are defined.

3.3 hybrid/

Use for deep work with automated support.

Examples:

review-committee.runtime.md
article-to-model-extraction.runtime.md
coding-project-plan-to-implementation.runtime.md

Hybrid Runtime is suitable when:

Core judgment is human-led.
Agents assist with critique or extraction.
Automation handles collection, formatting, routing, or archival.
Human approval is required for canonical changes.

4. Runtime Requirements

Each Runtime should define:

Purpose
Runtime Type
Operating Mode
Participants
Human Role
Agents
Skills
Tools
Input Contract
Shared Context
Authority
Human Decision Gates
Stages
Handoff Protocol
State Tracking
Output Format
Evaluation
Recovery
Archival Rules
Automation Boundary

5. Runtime vs Agent

An Agent is a role.

A Runtime is the operating system for a workflow.

Example:

cognitive-imaging-specialist.agent.md
= one reviewer

review-committee.runtime.md
= process that invokes several reviewers and synthesizes outputs

For projects and business systems that call CCPE Agents or Lite prompts, record this single CCPE external interface:

Interface.md

Interface.md routes consumers to the setup contract. The setup contract defines which additional CCPE files should be read for environment checks, invocation packets, specific Runtimes, and participant artifacts. Consumer projects should not memorize multiple CCPE paths as their default interface.

6. Runtime vs Skill

A Skill is a reusable capability.

A Runtime orchestrates capabilities.

Example:

model-mining.skill.md
= extract model from one source

article-to-model-extraction.runtime.md
= manage source intake, model extraction, human review, Model Card creation, and Model Index update

7. Runtime vs Automation

Not all Runtime is automation.

Interactive Runtime is often the correct form for deep thinking.

Do not automate conceptual decisions just because a Runtime exists.

8. Human Decision Gates

Every Runtime should explicitly mark human decision gates.

Examples:

Approve model extraction.
Choose which critique to accept.
Confirm Model Card promotion.
Approve code implementation plan.
Approve canonical file updates.

9. Naming Convention

Use lowercase kebab-case.

Recommended pattern:

{name}.runtime.md

Examples:

modeling-committee.runtime.md
review-committee.runtime.md
article-to-model-extraction.runtime.md

10. Runtime Metadata

Recommended front matter:

---
artifact_type: ccpe-runtime
name:
runtime_id:
author:
version:
created:
updated:
status:
runtime_type:
target_platform:
related_agents:
related_skills:
related_models:
based_on: CCPE System
---

11. Status Values

Use:

draft
experimental
active
deprecated
archived

12. Final Rule

Runtime exists to give complex work an operating structure.

It should make work more controllable, not more automatic by default.