chore: initialize cognitive os m0 m1

This commit is contained in:
wantsong 2026-06-20 01:07:28 +08:00
commit 4448bf210b
14 changed files with 1175 additions and 0 deletions

59
AGENTS.md Normal file
View File

@ -0,0 +1,59 @@
# Agent Instructions
This repository is the new `Cognitive-OS-Wantsong` project. It is not a continuation of `the-mindscape-of-bro-tsong`.
Before editing, read:
1. `README.md`
2. `PROJECTS.md`
3. `docs/PROJECT_BRIEF.md`
4. `docs/ASSET_MIGRATION_POLICY.md`
5. `docs/MODEL_MANAGEMENT_V0.md`
6. `docs/MODEL_ORCHESTRATION_V0.md`
## Hard Boundaries
- Treat the old project only as `model-governance-lab / asset-seed archive / anti-pattern reference`.
- Do not bulk-copy old directories or files into this repository.
- Do not create `ccra_review_bundle/`.
- Do not migrate old `reports/`.
- Do not migrate old `local_ccra_reviews/`.
- Do not import full regression suites, full selector calibration, lifecycle scan workflows, review-bundle packagers, or Round Conductor.
- Do not create sample runs, prompts, examples, or review packets during M0-M1 unless the owner explicitly starts a later milestone.
- Do not use `lite` in model filenames.
- Do not claim any model is final, accepted, approved, production-ready, or long-term core unless a milestone review explicitly records that decision.
## M0-M1 Working Rule
M0-M1 is allowed to define:
- project boundary;
- asset migration policy;
- minimal model status and registry rules;
- QPI as a routing model;
- Intellectual Archaeology as a deep-processing model;
- model orchestration fields needed later for primary/support selection.
M0-M1 is not allowed to run a sample or expand the model set.
## Model Roles
Use these role names in model cards and registry entries:
- `routing_model`
- `depth_model`
- `primary_model`
- `support_model`
- `contrast_model`
- `calibration_model`
- `translation_model`
- `synthesis_model`
Default posture:
- `qpi` is `routing_model`;
- `intellectual_archaeology` is `depth_model` and can become `primary_model` for high-value deep-processing cases.
## Local CCRA
Local CCRA is a milestone review lane only. It reviews milestone outputs and scope drift. It does not authorize repairs by itself, and it does not create public Web bundles by default.

44
PROJECTS.md Normal file
View File

@ -0,0 +1,44 @@
# Project Operating Notes
## Active Phase
Current phase: M0-M1 startup.
The active deliverable is a small file-first foundation for a cognitive-processing runtime. The repository should stay closer to runtime setup than governance evidence.
## Source Of Truth
This repository owns its own project boundary and model registry.
External materials are reference inputs only:
- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\Cognitive-OS-Wantsong项目总计划 v0.1.md`
- `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`
- selected Owner-authored cognitive-system source documents in `knowledge-vault`
The old project is not an upstream branch and not a source tree to merge.
## Milestone Order
1. M0: project boundary freeze.
2. M1: model-management kernel.
3. M2: prompt/runtime skeleton.
4. M3: reader translation prompt and before/after translation check.
5. M4: first real sample run.
6. M5: first Local CCRA milestone review.
Do not skip from M1 into sample execution without an explicit owner instruction.
## Supplier Boundaries
This repository may record requests for external reusable tooling later, but M0-M1 should not create a supplier-request channel unless a real missing tool blocks progress.
Reusable policy, reviewers, and broader CCRA method should stay outside this product repo unless the owner explicitly asks to localize a milestone protocol.
## Naming
Use kebab-case for filenames and directories.
Use snake_case for registry `model_id` values when the model identity already uses an underscore, for example `intellectual_archaeology`.
Do not use `lite` suffixes in filenames or model IDs.

89
README.md Normal file
View File

@ -0,0 +1,89 @@
# Cognitive-OS-Wantsong
status: m0_m1_startup
owner: Wantsong
date: 2026-06-20
## Product Definition
`Cognitive-OS-Wantsong` is a lightweight, file-first cognitive-processing runtime for Wantsong's personal model system.
The project goal is not to prove that model files can be governed. The first product question is:
```text
Given a real complex input, can the system chain Wantsong's cognitive models
and produce a useful internal cognitive-processing result plus a reader-facing translation?
```
The startup rule is:
```text
First prove cognitive processing.
Only then govern the pieces that prove useful.
```
## Current Milestone
This repository starts at M0-M1 only.
M0 freezes the project boundary:
- this is a new git repository, not a continuation branch of `the-mindscape-of-bro-tsong`;
- the old project is only an asset-seed archive and anti-pattern reference;
- old reports, review bundles, Local CCRA histories, selector calibration, full regression, and Round Conductor workflows are not migrated.
M1 creates the minimal model-management kernel:
- `models/qpi.md`;
- `models/intellectual-archaeology.md`;
- `models/model-registry.json`;
- model-management and orchestration rules under `docs/`.
## Not In Scope
Do not add these during M0-M1:
- sample runs;
- prompt runners;
- frontend or backend service;
- database, RAG, vector store, or knowledge graph;
- 10-model expansion;
- full model lifecycle system;
- full selector;
- full regression suite;
- Web review bundle;
- `ccra_review_bundle/`;
- old `reports/`;
- old `local_ccra_reviews/`;
- Round Conductor.
## Repository Map
```text
README.md
AGENTS.md
PROJECTS.md
docs/
PROJECT_BRIEF.md
COGNITIVE_WORKFLOW_V0.md
MODEL_MANAGEMENT_V0.md
MODEL_ORCHESTRATION_V0.md
READER_TRANSLATION_LAYER_V0.md
LOCAL_CCRA_MILESTONE_PROTOCOL.md
ASSET_MIGRATION_POLICY.md
DECISIONS.md
models/
qpi.md
intellectual-archaeology.md
model-registry.json
```
No model file uses a `lite` suffix. Minimality is expressed inside each model card with `runtime_scope: minimal_v0` and `governance_level: draft_callable`.
## Operating Posture
QPI is a front-routing and misframing-diagnostic model. It should not become the main product object again.
Intellectual Archaeology is the first deep-processing engine. It should be tested through real cognitive processing before expanding the model universe.
Local CCRA remains available only as a milestone review lane. It is not a default round factory.

View File

@ -0,0 +1,80 @@
# Asset Migration Policy
status: draft_runtime_policy
date: 2026-06-20
## Rule
Do not migrate directories. Migrate only selected principles or seed content, rewritten into this project's runtime language.
The old project is:
```text
model-governance-lab
asset-seed archive
historical reference
anti-pattern reference
```
It is not a parent codebase.
## Allowed Seed Sources
Allowed only as reference inputs:
- old QPI model/card material;
- old Intellectual Archaeology model/card material;
- selected source/excerpt structures;
- selected examples after later owner approval;
- `Wantsong认知操作系统.md`;
- the Intellectual Archaeology seven-layer example report;
- selected lessons from old governance explanations.
## Forbidden Migration
Do not copy or recreate:
- old `reports/`;
- old `ccra_review_bundle/`;
- old `local_ccra_reviews/`;
- full QPI regression suite;
- full selector calibration;
- before/after selector diff workflow;
- lifecycle-status scan workflow;
- review-bundle packager workflow;
- Round Conductor;
- old process manifests;
- old validation reports as project truth.
## Knowledge Asset Rule
Do not create the old-style `knowledge_assets/` directory in v0.1.
If a legacy principle is useful, rewrite it into one of these docs:
- `docs/PROJECT_BRIEF.md`;
- `docs/MODEL_MANAGEMENT_V0.md`;
- `docs/MODEL_ORCHESTRATION_V0.md`;
- `docs/LOCAL_CCRA_MILESTONE_PROTOCOL.md`;
- `docs/DECISIONS.md`.
## Rewrite Standard
A migrated principle must be rewritten so that it answers:
- how this runtime should process inputs;
- when a model should or should not be called;
- how output value will be inspected;
- how to prevent over-governance;
- what owner decision is needed before expansion.
Do not preserve old round labels, old bundle names, or old review evidence as operating rules.
## M0-M1 Migration Actually Used
M0-M1 uses the old project only to compress two seed model cards:
- `qpi`;
- `intellectual_archaeology`.
No reports, review bundles, Local CCRA histories, full regression suites, selector calibration sets, or lifecycle workflows are migrated.

View File

@ -0,0 +1,95 @@
# Cognitive Workflow V0
status: draft_workflow_contract
date: 2026-06-20
This file describes the intended runtime loop. It is not a sample run and does not authorize M0-M1 to create prompt files or examples.
## Runtime Flow
```text
1. Intake / Value Assessment
2. QPI
3. Lens Orchestrator
4. Deep Processing
5. Synthesis & Calibration
6. Feedback & Asset Decision
7. Reader Translation
```
## 1. Intake / Value Assessment
Purpose: decide whether the input deserves cognitive processing and what depth budget is justified.
Expected output:
- processing level: `L1 | L2 | L3 | L4`;
- reason for depth;
- whether heavy processing is justified;
- required context gaps.
## 2. QPI
Purpose: classify the issue framing before deeper work.
QPI outputs:
- `question | problem | issue | mixed | no_call`;
- owner and scenario;
- dominant scarcity;
- missing context;
- misframing risks;
- recommended next step.
QPI does not solve the problem. It only controls routing and prevents framing mistakes.
## 3. Lens Orchestrator
Purpose: choose a small set of models/lenses for this run.
Default call budget:
- one primary model;
- two or three support or contrast models at most;
- one calibration lens when needed;
- one reader translation layer when producing external-facing text.
M0-M1 only prepares the fields needed for this later choice. It does not implement a selector.
## 4. Deep Processing
Purpose: run the selected primary/depth model.
For startup, the only depth model is `intellectual_archaeology`. It should run only when the input has enough value, complexity, or reuse potential.
Depth processing must obey minimum sufficient depth. Continuing deeper is justified only when it changes judgment, path, validation, action boundary, or asset decision.
## 5. Synthesis & Calibration
Purpose: combine outputs and prevent a single model from over-claiming.
Expected output:
- main judgment;
- supporting reasoning;
- conflicts between model outputs;
- evidence level;
- action boundary;
- what would change the conclusion.
## 6. Feedback & Asset Decision
Purpose: decide whether the run produced reusable learning.
Expected output:
- whether the output was useful;
- whether the run should become a sample later;
- whether a model card needs a future repair;
- whether a new model need was exposed.
## 7. Reader Translation
Purpose: turn internal trace into a reader-facing explanation.
The internal output can contain model vocabulary and deep structure. The reader output must explain the actual issue, mechanism, example, boundary, and next way to think in language a non-model-maintainer can follow.

64
docs/DECISIONS.md Normal file
View File

@ -0,0 +1,64 @@
# Decisions
status: draft_decision_log
date: 2026-06-20
## D001: New Repository Boundary
Decision: `Cognitive-OS-Wantsong` is a new repository and not a continuation branch of `the-mindscape-of-bro-tsong`.
Reason: the old project is useful as a governance lab and seed archive, but its process gravity is not suitable for proving the runtime product question.
## D002: Runtime-First Startup Rule
Decision: the project follows `First prove cognitive processing. Only then govern the pieces that prove useful.`
Reason: the old failure mode was proving controlled model governance while postponing the real cognitive-processing loop.
## D003: M0-M1 Only
Decision: this startup creates only project boundary and model-management kernel files.
Reason: sample runs, prompts, examples, and review packets belong to later milestones.
## D004: No Lite Filenames
Decision: model filenames and model IDs do not use a `lite` suffix.
Reason: the new project is not a light branch of a completed old runtime. Minimality is expressed as `runtime_scope: minimal_v0`.
## D005: QPI Role
Decision: QPI is a `routing_model` for problem framing, scarcity diagnosis, and misframing detection.
Reason: QPI must not become the main governance object again.
## D006: Intellectual Archaeology Role
Decision: Intellectual Archaeology is the first `depth_model` and may be the primary model for complex high-value issues.
Reason: the new runtime must test real deep processing instead of mostly guarding the entrance to deep processing.
## D007: Local CCRA Lane
Decision: Local CCRA remains a milestone review lane only.
Reason: review quality remains useful, but default round factories and Web bundle production are outside the startup scope.
## D008: No Old Process Artifact Migration
Decision: old `reports/`, `ccra_review_bundle/`, `local_ccra_reviews/`, full regression, full selector calibration, lifecycle scan workflows, and Round Conductor are not migrated.
Reason: those artifacts represent the old project gravity and would recreate the failure mode.
## D009: Registry Before Selector
Decision: `models/model-registry.json` records model metadata and orchestration hooks, but no selector is implemented in M0-M1.
Reason: the system needs model identity and call boundaries before it needs automation.
## D010: Reader Translation As A Core Layer
Decision: reader translation is a first-class product layer, even though its prompt is not created in M0-M1.
Reason: internal model output is not automatically understandable or usable by frontend readers.

View File

@ -0,0 +1,62 @@
# Local CCRA Milestone Protocol
status: draft_milestone_lane
date: 2026-06-20
## Purpose
Local CCRA remains available as a milestone review lane.
It must not become a default round factory.
## Review Triggers
Use Local CCRA only at milestone boundaries, such as:
- project boundary ready;
- first end-to-end runtime sample complete;
- before adding the third or fourth model/lens;
- before converting repeated runtime outputs into governed model assets;
- before asking Web CCRA for formal acceptance.
## Non-Triggers
Do not start Local CCRA for:
- every prompt edit;
- small model note changes;
- routing wording changes;
- registry field additions;
- minor documentation cleanup.
## Review Package Shape
When a milestone review is explicitly started later, use a local-only directory such as:
```text
local-ccra-reviews/milestone-XX/01/
```
Expected files:
- `review-brief.md`;
- `file-manifest.md`;
- `prompt-to-send.md`;
- `LOCAL_CCRA_REVIEW_REPORT.md`;
- `returned-output.md`;
- `owner-decision.md`.
Optional only when needed:
- `helper-outputs/`;
- `next-review-requirements.md`.
## Authority
Local CCRA can identify findings and recommend repairs. It does not authorize repairs by itself.
Repairs require an owner decision. Web CCRA remains the strategic alignment and final-acceptance lane for major project direction.
## M0-M1 Boundary
M0-M1 defines this protocol only. It does not create a review directory or run a review.

100
docs/MODEL_MANAGEMENT_V0.md Normal file
View File

@ -0,0 +1,100 @@
# Model Management V0
status: draft_callable_kernel
date: 2026-06-20
## Purpose
Model management exists to make models callable in real cognitive processing. It is not the product itself.
M0-M1 defines enough structure to register and call the first two models:
- `qpi`;
- `intellectual_archaeology`.
## Model Status
Allowed statuses:
- `seed`: source material or rough idea, not callable.
- `draft`: model card exists but call boundary is incomplete.
- `callable`: usable in a manual runtime with known limits.
- `core_candidate`: repeatedly useful in real runs, pending milestone review.
- `core_active`: accepted by owner after multiple useful runs and milestone review.
- `needs_rework`: known boundary or quality issue blocks normal use.
- `deprecated`: no longer recommended for new runs.
- `archived`: retained only for history or reference.
M0-M1 may use only `draft` and `callable`.
## Model Levels
Allowed levels:
- `L0_source_material`: source article, discussion, report, or note.
- `L1_candidate_model`: extracted candidate model, not yet callable.
- `L2_callable_model`: callable manually with a known input/output contract.
- `L3_core_model`: future state after repeated useful runs and milestone review.
- `L4_long_term_core_model`: future state outside v0.1.
M0-M1 may use only `L1_candidate_model` and `L2_callable_model`.
## Required Model Card Fields
Each model card must state:
- `model_id`;
- file path;
- runtime scope;
- governance level;
- default role;
- allowed roles;
- one-sentence definition;
- call conditions;
- no-call conditions;
- input types;
- output contract;
- depth or cost controls;
- common misuses;
- reader translation requirement;
- source seed notes;
- current limits.
## Registry Requirements
`models/model-registry.json` is the only structured registry in M0-M1.
The registry must support:
- locating the model file;
- determining default role;
- identifying whether a model can be primary, support, contrast, calibration, translation, or routing;
- avoiding over-call by cost and no-call fields;
- pairing QPI with later deep processing;
- requiring reader translation when internal output is too model-heavy.
The registry is not a full schema system.
## Upgrade Rule
A model cannot be upgraded because JSON parses, docs exist, or a selector could call it.
Future upgrades require:
- real run evidence;
- owner review;
- quality review at a milestone;
- clear usefulness beyond one sample;
- explicit decision entry.
## Stop Conditions
Stop model-management expansion if work starts to require:
- complete evidence matrices before the first real runtime sample;
- a full regression suite;
- full selector calibration;
- lifecycle promotion machinery;
- proof that every boundary case is covered.
Those belong later, after the runtime proves value.

View File

@ -0,0 +1,84 @@
# Model Orchestration V0
status: draft_orchestration_boundary
date: 2026-06-20
## Purpose
Orchestration decides which small set of models should participate in a cognitive-processing run.
M0-M1 only defines the decision fields and call limits. It does not implement a selector.
## Roles
- `routing_model`: classifies input and controls next-step routing.
- `depth_model`: performs vertical deep processing.
- `primary_model`: main explanatory model for a run.
- `support_model`: fills a known blind spot of the primary model.
- `contrast_model`: challenges or reframes the primary model.
- `calibration_model`: checks evidence, action boundary, or overclaim risk.
- `translation_model`: rewrites internal output for reader use.
- `synthesis_model`: integrates outputs into a coherent judgment.
## Startup Defaults
`qpi`:
- default role: `routing_model`;
- should run before deep processing when problem framing is unclear;
- should stop at routing and misframing diagnosis.
`intellectual_archaeology`:
- default role: `depth_model`;
- can become `primary_model` for complex, high-value, reusable, or repeatedly failing issues;
- should run after intake/QPI justifies deeper work.
## Single-Run Call Budget
A normal run may include at most:
- one primary model;
- two or three support or contrast models;
- one calibration lens;
- one reader translation layer.
Do not call every related model. A model must add explanatory value, reduce a blind spot, or change the action boundary.
## Main Model Selection Signals
Primary model choice should consider:
- problem type match;
- explanatory gain;
- intended output;
- model maturity;
- processing cost.
Do not use simple keyword matching as the final selection method.
## Support Model Entry Conditions
A support model may enter only when:
- the primary model has a known blind spot;
- the primary model may over-explain;
- the issue needs comparison, contrast, or calibration.
## Guardrails
- QPI is not the product output.
- Intellectual Archaeology is not default for light tasks.
- No full selector in M0-M1.
- No flat scoring across a large model universe.
- No expansion beyond the two startup models without owner instruction.
## Future 100-Model Direction
If the project later grows toward many models, orchestration should use a layered path:
```text
input -> domain/problem family -> 5-8 candidates -> 1 primary -> 2-3 support/contrast -> calibration -> synthesis -> translation
```
This future direction is only a design hook. It is not part of v0.1 implementation.

76
docs/PROJECT_BRIEF.md Normal file
View File

@ -0,0 +1,76 @@
# Project Brief
status: draft_runtime_boundary
date: 2026-06-20
## One-Sentence Definition
`Cognitive-OS-Wantsong` is a lightweight cognitive-processing runtime that uses Wantsong's cognitive models to process complex inputs into internal analysis and reader-facing explanations.
## Restart Basis
The old project proved useful file-first model-governance mechanisms, but its operating gravity drifted toward review evidence, selector calibration, regression cases, and lifecycle caution.
This project starts from the opposite order:
```text
run real cognitive workflow -> inspect output value -> stabilize useful model pieces
```
M0-M1 therefore creates only the boundary and model-management kernel required before any runtime sample.
## Product Layers
The project has three layers and one review lane:
1. Model management layer: register, describe, call, combine, retire, and repair model assets.
2. Cognitive-processing runtime layer: intake, QPI, lens orchestration, deep processing, synthesis, calibration, and feedback.
3. Reader translation layer: turn internal model output into understandable reader-facing expression.
4. Milestone quality lane: Local CCRA reviews milestone outputs, not every small edit.
## M0 Acceptance
M0 is acceptable when:
- the repo has an independent git boundary and remote;
- the old project is documented only as reference and seed archive;
- forbidden old process artifacts are not present;
- v0.1 non-goals are explicit.
## M1 Acceptance
M1 is acceptable when:
- QPI and Intellectual Archaeology have callable model cards;
- `models/model-registry.json` supports future primary/support selection;
- model statuses and levels are defined without creating a full lifecycle system;
- no full selector, full schema validator, sample run, or regression suite exists.
## Non-Goals For v0.1 Startup
- full model library;
- 10-model expansion;
- complete schema validator;
- database;
- backend service;
- frontend UI;
- vector database;
- full RAG;
- full regression suite;
- lifecycle promotion;
- before/after selector diff;
- Web review bundle by default;
- old report migration;
- old review-bundle migration;
- old Local CCRA history migration;
- Round Conductor.
## Failure Signals
M0-M1 is drifting if:
- QPI becomes the main governance object again;
- review artifacts outgrow runtime artifacts before the first sample;
- Codex creates `round-*`, `ccra_review_bundle/`, or full regression material;
- model management starts requiring perfect evidence matrices before any runtime use;
- reader translation is ignored as a product layer.

View File

@ -0,0 +1,52 @@
# Reader Translation Layer V0
status: draft_translation_boundary
date: 2026-06-20
## Purpose
Internal cognitive processing can use Wantsong's model vocabulary, formulas, metaphors, layered reasoning, and mechanism chains.
Reader-facing output cannot simply expose that internal trace. It must translate the result into language a reader can use.
## Output Modes
M0-M1 recognizes these modes:
- `R0_internal_trace`: internal analysis record for owner inspection.
- `R1_owner_brief`: compact owner-facing quality summary.
- `R2_reader_explanation`: explanation for a normal reader.
- `R3_publishable_draft`: future writing-workbench draft.
- `R4_product_response`: future product answer.
v0.1 targets only `R0_internal_trace` and `R2_reader_explanation`.
## Translation Operations
Reader translation performs four operations:
1. Terminology translation: replace model jargon with ordinary language.
2. Structure translation: reorder the reasoning so a reader can follow it.
3. Example translation: use concrete examples to carry abstract mechanisms.
4. Action translation: turn insight into "how to see this / what to consider next".
## What To Preserve
- core insight;
- mechanism;
- boundaries;
- Wantsong-style distinction and depth;
- practical next way to think.
## What To Remove Or Compress
- full model trace;
- unnecessary formulas;
- seven-layer expansion when only three layers matter;
- governance vocabulary;
- generic disclaimers;
- marketing exaggeration.
## Boundary
This layer is defined now because it changes model-card requirements. The actual translation prompt is not created in M0-M1.

View File

@ -0,0 +1,110 @@
# Intellectual Archaeology
model_id: intellectual_archaeology
file: models/intellectual-archaeology.md
runtime_scope: minimal_v0
governance_level: draft_callable
status: callable
model_level: L2_callable_model
default_role: depth_model
allowed_roles: depth_model, primary_model
reader_translation_required: true
## One-Sentence Definition
Intellectual Archaeology is a depth-processing model that drills from surface application down through deeper structural layers to expose hidden assumptions, core mechanisms, and action-relevant boundaries.
## Runtime Role
Intellectual Archaeology is the first deep-processing engine in this project.
It is not a front router, not a summary format, and not a default response style. It should be called only when Intake and QPI indicate that deeper modeling is worth the cost.
## Core Question
What deeper structural assumptions make this issue, model, or judgment work, and at what depth does further excavation stop changing the decision?
## Layer Framework
The model uses seven possible layers:
1. `application`: surface task, tool, behavior, or symptom.
2. `domain`: domain topology, evaluation frame, actors, and constraints.
3. `process`: time evolution, feedback, lifecycle, and path dependence.
4. `purpose`: value target, tradeoff, stakeholder balance, and QPI alignment.
5. `core_mechanism`: generative mechanism, system dynamics, and causal structure.
6. `human_capability`: cognitive, biological, organizational, or skill limits.
7. `philosophical_bedrock`: basic assumptions about reality, meaning, order, and agency.
## Minimum Sufficient Depth
Do not automatically drill to the deepest layer.
Continue deeper only if it changes at least one of:
- judgment;
- solution path;
- evidence requirement;
- risk weighting;
- action boundary;
- reusable model asset decision.
## Call When
- QPI classifies the input as a medium/heavy `problem` or `issue`.
- A surface explanation keeps failing.
- The issue has high reuse value.
- The owner wants to extract a model from source material.
- The problem needs hidden assumptions made explicit.
- A model or product logic needs depth inspection.
## Do Not Call When
- The input is a fact lookup.
- The user needs a short execution answer.
- There is not enough source material to distinguish mechanism from speculation.
- Deeper analysis will not change judgment or action.
- The user explicitly asks not to enter depth processing.
## Input Types
- complex issue;
- recurring failure;
- cognitive model draft;
- source article or report for model extraction;
- strategic, product, or organizational reasoning problem;
- hidden-assumption audit.
## Output Contract
Intellectual Archaeology output must include:
- `should_call`;
- `entry_reason`;
- `recommended_max_depth`;
- `layers_to_analyze`;
- `analysis_by_layer`;
- `stop_reason`;
- `no_deeper_reason`;
- `assumptions_by_layer`;
- `core_mechanism_summary`;
- `validation_needed`;
- `action_implication`;
- `reader_translation_notes`.
## Common Misuses
- Using the model as a long summary.
- Forcing every issue to the philosophical layer.
- Producing abstract depth without changing action.
- Ignoring QPI and value-assessment controls.
- Treating internal coherence as real-world validity.
- Forgetting reader translation.
## Source Seed Notes
Seeded from the old Intellectual Archaeology model/card and the seven-layer example report, rewritten for this runtime. Old regression suites, selector gates, review reports, and Local CCRA histories are not migrated.
## Current Limits
This model is callable for manual runtime use, but its depth stops and layer quality require real-run calibration before any upgrade.

127
models/model-registry.json Normal file
View File

@ -0,0 +1,127 @@
{
"registry_id": "cognitive_os_wantsong_model_registry",
"version": "0.1.0",
"date": "2026-06-20",
"runtime_scope": "minimal_v0",
"status": "draft_callable_registry",
"notes": [
"M0-M1 registry only. This is not a full selector, schema system, or lifecycle engine.",
"No model filenames or model IDs use lite suffixes.",
"Old review bundles, reports, Local CCRA histories, full regression, and selector calibration are not migrated."
],
"allowed_roles": [
"routing_model",
"depth_model",
"primary_model",
"support_model",
"contrast_model",
"calibration_model",
"translation_model",
"synthesis_model"
],
"single_run_call_budget": {
"primary_model_max": 1,
"support_or_contrast_model_max": 3,
"calibration_model_max": 1,
"translation_model_max": 1
},
"models": [
{
"model_id": "qpi",
"display_name": "QPI",
"file": "models/qpi.md",
"model_family": "problem_framing",
"status": "callable",
"model_level": "L2_callable_model",
"runtime_scope": "minimal_v0",
"governance_level": "draft_callable",
"default_role": "routing_model",
"allowed_roles": [
"routing_model",
"calibration_model"
],
"pipeline_position": "pre_analysis",
"can_be_primary": false,
"can_be_support": true,
"can_be_contrast": false,
"can_be_calibration": true,
"reader_translation_required": true,
"best_for": [
"problem_definition",
"dominant_scarcity_detection",
"misframing_risk",
"routing_before_depth"
],
"avoid_for": [
"fact_lookup",
"direct_execution",
"copyediting",
"final_answer_generation"
],
"cost_level": "low",
"call_before": [
"intellectual_archaeology"
],
"call_after": [],
"pairs_well_with": [
"intellectual_archaeology"
],
"conflicts_with": [],
"source_seed": [
"old_project_cards_qpi",
"old_project_models_qpi",
"wantsong_cognitive_os_source"
]
},
{
"model_id": "intellectual_archaeology",
"display_name": "Intellectual Archaeology",
"file": "models/intellectual-archaeology.md",
"model_family": "deep_modeling",
"status": "callable",
"model_level": "L2_callable_model",
"runtime_scope": "minimal_v0",
"governance_level": "draft_callable",
"default_role": "depth_model",
"allowed_roles": [
"depth_model",
"primary_model"
],
"pipeline_position": "deep_analysis",
"can_be_primary": true,
"can_be_support": false,
"can_be_contrast": false,
"can_be_calibration": false,
"reader_translation_required": true,
"best_for": [
"deep_structure",
"hidden_assumptions",
"mechanism_excavation",
"reusable_model_extraction",
"recurring_failure_analysis"
],
"avoid_for": [
"fact_lookup",
"light_rewrite",
"low_stakes_execution",
"insufficient_source_material"
],
"cost_level": "high",
"call_before": [],
"call_after": [
"qpi"
],
"pairs_well_with": [
"qpi"
],
"conflicts_with": [
"fast_execution_flow"
],
"source_seed": [
"old_project_cards_intellectual_archaeology",
"old_project_models_intellectual_archaeology",
"seven_layer_ia_example_report"
]
}
]
}

133
models/qpi.md Normal file
View File

@ -0,0 +1,133 @@
# QPI
model_id: qpi
file: models/qpi.md
runtime_scope: minimal_v0
governance_level: draft_callable
status: callable
model_level: L2_callable_model
default_role: routing_model
allowed_roles: routing_model, calibration_model
reader_translation_required: true
## One-Sentence Definition
QPI classifies how a cognitive subject frames an expectation-reality gap as `question`, `problem`, `issue`, `mixed`, or `no_call`, then identifies missing context, dominant scarcity, dynamic stage, and misframing risk.
## Runtime Role
QPI is a front-routing and misframing-diagnostic model.
It should run before deep processing when problem framing is unclear. It should not replace deep processing, synthesis, or final answer generation.
## Core Question
Who, in what scenario, frames which expectation-reality gap as what kind of problem, and what context is missing before the framing can be trusted?
## Core Mechanism
QPI checks:
- problem owner;
- subject position;
- scenario context;
- responsibility scope;
- problem source;
- time scale;
- expectation-reality gap;
- three scarcity types.
Scarcity mapping:
- `question`: data or fact scarcity;
- `problem`: path, method, or resource scarcity;
- `issue`: consensus, certainty, order, or dynamic-balance scarcity;
- `mixed`: multiple scarcity types in the same subject/scenario frame;
- `no_call`: input does not need QPI.
QPI must distinguish same-frame mixed scarcity from cross-viewpoint divergence.
## Call When
- The user asks what the real problem is.
- The input mixes facts, path constraints, interests, and system structure.
- The problem owner or responsibility boundary is unclear.
- The user is rushing to solve before defining the issue.
- There is risk of violent reduction, malicious inflation, or means-end mismatch.
- A later model needs routing support.
## Do Not Call When
- The user only asks for a clear fact lookup.
- The user gives a direct execution task.
- The user asks for copyediting or format conversion.
- The problem has already been framed and only needs the next execution step.
- The user explicitly asks not to analyze, unless they narrowly request QPI-only classification.
## Input Types
- ambiguous problem statement;
- business or product issue description;
- organizational conflict narrative;
- unclear requirement or failure report;
- owner reflection that needs problem-definition help.
## Output Contract
QPI output must include:
- `classification_scope`: `subject_contextual | multi_perspective | insufficient_context | no_call`;
- `classification`: `question | problem | issue | mixed | no_call`;
- `classification_confidence`: `high | medium | low`;
- `is_provisional`;
- `problem_owner`;
- `subject_position`;
- `scenario_context`;
- `responsibility_scope`;
- `problem_source`;
- `time_scale`;
- `expectation_reality_gap`;
- `context_sufficiency`;
- `missing_context`;
- `scarcity_profile`;
- `dominant_scarcity`;
- `classification_reason`;
- `classification_by_viewpoint`;
- `dynamic_stage`;
- `possible_trajectory`;
- `success_criteria_stability`;
- `hard_feedback_availability`;
- `governance_load`;
- `evidence_gap`;
- `misclassification_risk`;
- `recommended_clarifying_questions`;
- `recommended_next_step`;
- `next_model_candidates`.
## Depth Control
Stop at QPI when:
- the input is a fact lookup;
- classification evidence is too thin;
- the user only needs a narrow problem-type judgment;
- negative triggers suppress analysis.
Recommend `intellectual_archaeology` only when the issue is high-value, recurring, structurally complex, or likely to benefit from depth processing.
## Common Misuses
- Treating QPI as a full answer.
- Turning QPI into the main governance battlefield.
- Classifying by keywords without owner/scenario context.
- Calling every complex-looking input an `issue`.
- Collapsing cross-viewpoint divergence into same-frame `mixed`.
- Using QPI to delay a direct fact lookup or simple execution task.
## Source Seed Notes
Seeded from the old QPI model/card and Wantsong cognitive-system source material, rewritten for this runtime. Old regression suites, selector calibration, and review artifacts are not migrated.
## Current Limits
This model is callable for manual runtime use, but it is not a reviewed core model. It needs real-run evidence before any upgrade.