Compare commits
44 Commits
c861520ccd
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
| cd8339ecef | |||
| f8ab58edbe | |||
| 2b5e9743fe | |||
| 753c3d4fc6 | |||
| 94e84f0db9 | |||
| a765ccda21 | |||
| 4472fa6c7f | |||
| 526fa1e3bc | |||
| 86de18c247 | |||
| ca9d0d7030 | |||
| bc527ec09a | |||
| ce984482e2 | |||
| 9266f124e6 | |||
| 8740a66611 | |||
| b7e9edbb4b | |||
| 479fa95fdf | |||
| eb9b622499 | |||
| e3e5b8ecc1 | |||
| 9e8d73fa7d | |||
| d44a4cd3df | |||
| c0615c2d50 | |||
| 965508ec06 | |||
| f325f89dc9 | |||
| 36a5136bdf | |||
| b7e11461f4 | |||
| 3966814868 | |||
| f4610a46e3 | |||
| 0d95e6dbcf | |||
| 36c20f37d0 | |||
| 72b87fd82e | |||
| eaf4a955af | |||
| e9dc9a8517 | |||
| b055c8d7bb | |||
| ef3d47779e | |||
| d1f57272a4 | |||
| a9ca0adfcf | |||
| 81a4c8796a | |||
| 2d45425b25 | |||
| fa27572f43 | |||
| dfab3d598b | |||
| 34ed7a6fab | |||
| 7f1eecbdb2 | |||
| 574bb11db6 | |||
| 8f00fa2018 |
20
.claude/rules/agents.md
Normal file
20
.claude/rules/agents.md
Normal file
@@ -0,0 +1,20 @@
|
|||||||
|
## Kaizen Agents
|
||||||
|
|
||||||
|
Specialized agent personas available on demand via the state-hub MCP.
|
||||||
|
|
||||||
|
**Discover:** `list_kaizen_agents()` — returns all agents with name, description, category
|
||||||
|
**Load:** `get_kaizen_agent("tdd-workflow")` — returns full instructions; read and follow them
|
||||||
|
|
||||||
|
Common agents:
|
||||||
|
|
||||||
|
| Agent | Category | When to use |
|
||||||
|
|-------|----------|-------------|
|
||||||
|
| `tdd-workflow` | testing | Step-by-step TDD8 workflow for any feature |
|
||||||
|
| `code-refactoring` | quality | Code quality analysis and safe refactoring |
|
||||||
|
| `test-maintenance` | testing | Diagnose and fix failing tests |
|
||||||
|
| `requirements-engineering` | process | Prevent interface/mock mismatches upfront |
|
||||||
|
| `keepaTodofile` | process | Maintain TODO.md during work |
|
||||||
|
| `project-management` | process | Track status, determine next steps |
|
||||||
|
| `datamodel-optimization` | quality | Optimize dataclasses and data structures |
|
||||||
|
|
||||||
|
All 17 agents: call `list_kaizen_agents()` for the full list.
|
||||||
8
.claude/rules/architecture.md
Normal file
8
.claude/rules/architecture.md
Normal file
@@ -0,0 +1,8 @@
|
|||||||
|
## Architecture
|
||||||
|
|
||||||
|
<!-- TODO: Describe the key design decisions and component structure.
|
||||||
|
Key modules, data flows, external integrations, state machines, etc. -->
|
||||||
|
|
||||||
|
## Quick Reference
|
||||||
|
|
||||||
|
`~/state-hub/mcp_server/TOOLS.md` — MCP tool reference
|
||||||
50
.claude/rules/credential-routing.md
Normal file
50
.claude/rules/credential-routing.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
# Credential and access routing
|
||||||
|
|
||||||
|
**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
|
||||||
|
for inference. Run this check **before** requesting secrets, API keys, SSH access,
|
||||||
|
login tokens, or database passwords — in any repo, not only `ops-warden`.
|
||||||
|
|
||||||
|
ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
|
||||||
|
other credential need belongs to another subsystem. **Do not** message
|
||||||
|
`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
|
||||||
|
|
||||||
|
### Lookup (do this first)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
warden route find "<describe your need>" --json
|
||||||
|
warden route show <catalog-id> --json
|
||||||
|
```
|
||||||
|
|
||||||
|
Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
|
||||||
|
|
||||||
|
| Agent runtime | How to orient |
|
||||||
|
| --- | --- |
|
||||||
|
| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=markitect-main` is for coordination, not secret vending |
|
||||||
|
| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
|
||||||
|
| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
|
||||||
|
|
||||||
|
### Quick routing table
|
||||||
|
|
||||||
|
| I need… | Owner | ops-warden executes? |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
|
||||||
|
| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
|
||||||
|
| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
|
||||||
|
| Authorization decision | flex-auth | No — route only |
|
||||||
|
| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
|
||||||
|
| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
|
||||||
|
|
||||||
|
### Anti-patterns (do not do these)
|
||||||
|
|
||||||
|
- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
|
||||||
|
- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
|
||||||
|
- Pasting secrets into Git, State Hub, workplans, logs, or chat
|
||||||
|
|
||||||
|
### Other capabilities (reuse-surface)
|
||||||
|
|
||||||
|
Non-credential capabilities are usually discovered through **reuse-surface** federation
|
||||||
|
(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
|
||||||
|
every repo's agent instructions because it is high-frequency, high-risk, and easy to
|
||||||
|
get wrong.
|
||||||
|
|
||||||
|
**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
|
||||||
38
.claude/rules/first-session.md
Normal file
38
.claude/rules/first-session.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
## First Session Protocol
|
||||||
|
|
||||||
|
Triggered when `get_domain_summary("communication")` shows **no workstreams**.
|
||||||
|
The project is registered but work has not yet been structured.
|
||||||
|
|
||||||
|
**Step 1 — Read, don't write**
|
||||||
|
- `~/the-custodian/canon/projects/communication/project_charter_v0.1.md` — purpose, scope
|
||||||
|
- `~/the-custodian/canon/projects/communication/roadmap_v0.1.md` — planned phases
|
||||||
|
- Scan repo root: README, directory structure, existing code or docs
|
||||||
|
|
||||||
|
**Step 2 — Survey in-progress work**
|
||||||
|
Look for TODOs, open branches, half-finished files. Note done vs. started but incomplete.
|
||||||
|
|
||||||
|
**Step 3 — Propose workstreams to Bernd**
|
||||||
|
Propose 1–3 workstreams — each a coherent strand, weeks to months, anchored to a
|
||||||
|
roadmap phase. **Wait for approval before creating.**
|
||||||
|
|
||||||
|
**Step 4 — Create workplan file first, then DB record (ADR-001)**
|
||||||
|
```
|
||||||
|
workplans/MARKITECT-WP-NNNN-<slug>.md ← write this first
|
||||||
|
```
|
||||||
|
Then register in the hub:
|
||||||
|
```
|
||||||
|
create_workstream(topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc", title="...", owner="...", description="...")
|
||||||
|
create_task(workstream_id="<id>", title="...", priority="high|medium|low")
|
||||||
|
```
|
||||||
|
|
||||||
|
**Step 5 — Record the setup**
|
||||||
|
```
|
||||||
|
add_progress_event(
|
||||||
|
summary="First session: structured communication into N workstreams, M tasks",
|
||||||
|
event_type="milestone",
|
||||||
|
topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc",
|
||||||
|
detail={"workstreams": [...], "tasks_created": M}
|
||||||
|
)
|
||||||
|
```
|
||||||
|
|
||||||
|
<!-- Delete or archive this file once past first session -->
|
||||||
8
.claude/rules/repo-boundary.md
Normal file
8
.claude/rules/repo-boundary.md
Normal file
@@ -0,0 +1,8 @@
|
|||||||
|
## Repo boundary
|
||||||
|
|
||||||
|
This repo owns **Markitect Main** only. It does not own:
|
||||||
|
|
||||||
|
<!-- TODO: List what belongs in adjacent repos, e.g.:
|
||||||
|
- SSH key management → railiance-infra/
|
||||||
|
- State hub code → state-hub/
|
||||||
|
-->
|
||||||
5
.claude/rules/repo-identity.md
Normal file
5
.claude/rules/repo-identity.md
Normal file
@@ -0,0 +1,5 @@
|
|||||||
|
**Purpose:** Markitect Main - (fill in purpose)
|
||||||
|
|
||||||
|
**Domain:** communication
|
||||||
|
**Repo slug:** markitect-main
|
||||||
|
**Topic ID:** 36c7421b-c537-4723-bf75-42a3ebc6a1dc
|
||||||
85
.claude/rules/session-protocol.md
Normal file
85
.claude/rules/session-protocol.md
Normal file
@@ -0,0 +1,85 @@
|
|||||||
|
## Session Protocol
|
||||||
|
|
||||||
|
Dev Hub (State Hub API): http://127.0.0.1:8000
|
||||||
|
MCP server name in `~/.claude.json`: `dev-hub`
|
||||||
|
|
||||||
|
**Step 1 — Orient**
|
||||||
|
|
||||||
|
Read the offline-safe brief first — it works without a live hub connection:
|
||||||
|
```bash
|
||||||
|
cat .custodian-brief.md
|
||||||
|
```
|
||||||
|
Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
|
||||||
|
```
|
||||||
|
get_domain_summary("communication")
|
||||||
|
```
|
||||||
|
If MCP tools are unavailable in the current agent session, use the REST API:
|
||||||
|
```bash
|
||||||
|
curl -s "http://127.0.0.1:8000/state/summary" | python3 -m json.tool
|
||||||
|
```
|
||||||
|
If the hub is offline: `cd ~/state-hub && make api`
|
||||||
|
|
||||||
|
**Step 2 — Check inbox**
|
||||||
|
With MCP tools:
|
||||||
|
```
|
||||||
|
get_messages(to_agent="markitect-main", unread_only=True)
|
||||||
|
```
|
||||||
|
Mark read with `mark_message_read(message_id)`. Reply or act on coordination
|
||||||
|
requests before proceeding.
|
||||||
|
|
||||||
|
Without MCP tools:
|
||||||
|
```bash
|
||||||
|
curl -s "http://127.0.0.1:8000/messages/?to_agent=markitect-main&unread_only=true" \
|
||||||
|
| python3 -m json.tool
|
||||||
|
curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
|
||||||
|
-H "Content-Type: application/json" -d '{}'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Step 3 — Scan workplans**
|
||||||
|
```bash
|
||||||
|
ls workplans/
|
||||||
|
```
|
||||||
|
For each file with `status: ready`, `active`, or `blocked`, note pending
|
||||||
|
`wait`/`todo`/`progress` tasks.
|
||||||
|
|
||||||
|
**Step 4 — Present brief**
|
||||||
|
|
||||||
|
1. **Active workstreams** for `communication` — title, task counts, blocking decisions
|
||||||
|
2. **Pending tasks** from `workplans/` + any `[repo:markitect-main]` hub tasks
|
||||||
|
3. **Goal guidance** — if `goal_guidance` in summary:
|
||||||
|
- `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
|
||||||
|
- `alignment_warnings`: flag if active work is not aligned with current goal
|
||||||
|
4. **Suggested next action** — highest-priority open item
|
||||||
|
5. **SBOM status** — flag if `last_sbom_at` is unset for this repo
|
||||||
|
|
||||||
|
If no workstreams: follow First Session Protocol (`first-session.md`).
|
||||||
|
|
||||||
|
**During work:** `record_decision()` · `add_progress_event()` · `resolve_decision()`
|
||||||
|
|
||||||
|
> State Hub is a *read model*. Bootstrap tools (`create_workstream`, `create_task`)
|
||||||
|
> are First Session Protocol only. Work structure belongs in repo files (ADR-001).
|
||||||
|
|
||||||
|
**Session close:**
|
||||||
|
With MCP tools:
|
||||||
|
```
|
||||||
|
add_progress_event(summary="...", topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc", workstream_id="<uuid>")
|
||||||
|
```
|
||||||
|
Without MCP tools:
|
||||||
|
```bash
|
||||||
|
curl -s -X POST http://127.0.0.1:8000/progress/ \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{"topic_id":"36c7421b-c537-4723-bf75-42a3ebc6a1dc","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
|
||||||
|
```
|
||||||
|
If workplan files were modified, ensure the local copy is up to date first:
|
||||||
|
```bash
|
||||||
|
git -C <repo_path> pull --ff-only
|
||||||
|
cd ~/state-hub && make fix-consistency REPO=markitect-main
|
||||||
|
```
|
||||||
|
For repos where implementation runs on a remote machine (e.g. CoulombCore),
|
||||||
|
use the combined target which pulls before fixing:
|
||||||
|
```bash
|
||||||
|
cd ~/state-hub && make fix-consistency-remote REPO=markitect-main
|
||||||
|
```
|
||||||
|
**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
|
||||||
|
will sync the file to match DB. **C-16** (repo behind remote) blocks all writes
|
||||||
|
until you pull — intentional to prevent clobbering remote progress.
|
||||||
16
.claude/rules/stack-and-commands.md
Normal file
16
.claude/rules/stack-and-commands.md
Normal file
@@ -0,0 +1,16 @@
|
|||||||
|
## Stack
|
||||||
|
|
||||||
|
- **Language:** Python 3.12+ (monorepo) + JavaScript UI (testdrive-jsui)
|
||||||
|
- **Key deps:** uv/pip, pytest, npm; see `pyproject.toml`, `package.json`, `Makefile`
|
||||||
|
|
||||||
|
## Dev Commands
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make setup
|
||||||
|
make test
|
||||||
|
make test-js
|
||||||
|
make test-all
|
||||||
|
make lint
|
||||||
|
make build
|
||||||
|
make help
|
||||||
|
```
|
||||||
40
.claude/rules/workplan-convention.md
Normal file
40
.claude/rules/workplan-convention.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
## Workplan Convention (ADR-001)
|
||||||
|
|
||||||
|
File location: `workplans/MARKITECT-WP-NNNN-<slug>.md`
|
||||||
|
ID prefix: `MARKITECT-WP-`
|
||||||
|
|
||||||
|
Work items originate as files in this repo **before** being registered in the hub.
|
||||||
|
|
||||||
|
Canonical workplan/workstream frontmatter statuses are:
|
||||||
|
`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
|
||||||
|
Use `proposed` for a newly drafted plan, `ready` after review against current
|
||||||
|
repo state, and `finished` when implementation is complete. `stalled` and
|
||||||
|
`needs_review` are derived health labels, not stored statuses.
|
||||||
|
|
||||||
|
Closed workplans may be moved to `workplans/archived/` with a completion-date
|
||||||
|
prefix: `YYMMDD-MARKITECT-WP-NNNN-<slug>.md`. The frontmatter id remains
|
||||||
|
unchanged; the prefix is only for quick visual reference.
|
||||||
|
|
||||||
|
Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
|
||||||
|
`workplans/ADHOC-YYYY-MM-DD.md`, workstream slug `adhoc-YYYY-MM-DD`, and task ids
|
||||||
|
`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
|
||||||
|
directly. Promote anything requiring analysis, design, approval, dependencies, or
|
||||||
|
multiple planned phases into a normal workplan.
|
||||||
|
|
||||||
|
Ecosystem todos from other agents arrive as `[repo:markitect-main]` hub tasks —
|
||||||
|
visible at session start. Pick one up by creating the workplan file, then registering
|
||||||
|
the workstream.
|
||||||
|
|
||||||
|
Task blocks use this shape:
|
||||||
|
|
||||||
|
```task
|
||||||
|
id: MARKITECT-WP-NNNN-T01
|
||||||
|
status: wait | todo | progress | done | cancel
|
||||||
|
priority: high | medium | low
|
||||||
|
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit
|
||||||
|
```
|
||||||
|
|
||||||
|
Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
|
||||||
|
blocked work and `cancel` for stopped work.
|
||||||
|
|
||||||
|
<!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->
|
||||||
@@ -10,7 +10,7 @@ principles with strict separation of concerns.
|
|||||||
|
|
||||||
## Directory Structure & Clean Architecture
|
## Directory Structure & Clean Architecture
|
||||||
```
|
```
|
||||||
markitect_project/
|
markitect-main/
|
||||||
├── domain/ # Business logic (innermost layer)
|
├── domain/ # Business logic (innermost layer)
|
||||||
├── application/ # Use cases and workflows
|
├── application/ # Use cases and workflows
|
||||||
├── infrastructure/ # External interfaces (database, file system)
|
├── infrastructure/ # External interfaces (database, file system)
|
||||||
|
|||||||
18
.custodian-brief.md
Normal file
18
.custodian-brief.md
Normal file
@@ -0,0 +1,18 @@
|
|||||||
|
<!-- custodian-brief: generated by fix-consistency — do not edit manually -->
|
||||||
|
# Custodian Brief — markitect-main
|
||||||
|
|
||||||
|
**Domain:** communication
|
||||||
|
**Last synced:** 2026-06-22 21:32 UTC
|
||||||
|
**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
|
||||||
|
|
||||||
|
## Active Workstreams
|
||||||
|
|
||||||
|
*(none — repo may need first-session setup)*
|
||||||
|
|
||||||
|
---
|
||||||
|
## MCP Orientation (when available)
|
||||||
|
|
||||||
|
If the state-hub MCP server is reachable, call:
|
||||||
|
`get_domain_summary("communication")`
|
||||||
|
This provides richer cross-domain context.
|
||||||
|
If the MCP call fails, use this file as your orientation source.
|
||||||
2
.gitignore
vendored
2
.gitignore
vendored
@@ -91,6 +91,8 @@ debug_*.py
|
|||||||
|
|
||||||
# Claude Code local settings (user-specific permissions)
|
# Claude Code local settings (user-specific permissions)
|
||||||
.claude/settings.local.json
|
.claude/settings.local.json
|
||||||
|
# Claude Code runtime session locks (per-session, not content)
|
||||||
|
.claude/*.lock
|
||||||
|
|
||||||
.aider*
|
.aider*
|
||||||
|
|
||||||
|
|||||||
2
.gitmodules
vendored
2
.gitmodules
vendored
@@ -1,6 +1,6 @@
|
|||||||
[submodule "wiki"]
|
[submodule "wiki"]
|
||||||
path = wiki
|
path = wiki
|
||||||
url = http://92.205.130.254:32166/coulomb/markitect_project.wiki.git
|
url = http://92.205.130.254:32166/coulomb/markitect-main.wiki.git
|
||||||
branch = main
|
branch = main
|
||||||
[submodule "capabilities/kaizen-agentic"]
|
[submodule "capabilities/kaizen-agentic"]
|
||||||
path = capabilities/kaizen-agentic
|
path = capabilities/kaizen-agentic
|
||||||
|
|||||||
25
.repo-classification.yaml
Normal file
25
.repo-classification.yaml
Normal file
@@ -0,0 +1,25 @@
|
|||||||
|
repo_classification:
|
||||||
|
standard: Repo Classification Standard
|
||||||
|
version: '1.0'
|
||||||
|
classified_at: '2026-06-22'
|
||||||
|
classified_by: human
|
||||||
|
category: product
|
||||||
|
domain: communication
|
||||||
|
secondary_domains:
|
||||||
|
- infotech
|
||||||
|
- agents
|
||||||
|
capability_tags:
|
||||||
|
- knowledge
|
||||||
|
- documentation
|
||||||
|
- product-development
|
||||||
|
- platform
|
||||||
|
business_stake:
|
||||||
|
- product
|
||||||
|
- technology
|
||||||
|
- execution
|
||||||
|
business_mechanics:
|
||||||
|
- intention
|
||||||
|
- coordination
|
||||||
|
- operation
|
||||||
|
- adaptation
|
||||||
|
notes: Markitect successor to archived markitect-project; human confirmed.
|
||||||
219
AGENTS.md
Normal file
219
AGENTS.md
Normal file
@@ -0,0 +1,219 @@
|
|||||||
|
# Markitect Main — Agent Instructions
|
||||||
|
|
||||||
|
## Repo Identity
|
||||||
|
|
||||||
|
**Purpose:** Markitect Main - (fill in purpose)
|
||||||
|
|
||||||
|
**Domain:** communication
|
||||||
|
**Repo slug:** markitect-main
|
||||||
|
**Topic ID:** `36c7421b-c537-4723-bf75-42a3ebc6a1dc`
|
||||||
|
**Workplan prefix:** `MARKITECT-WP-`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## State Hub Integration
|
||||||
|
|
||||||
|
The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
|
||||||
|
there is no MCP server for Codex agents.
|
||||||
|
|
||||||
|
| Context | URL |
|
||||||
|
|---------|-----|
|
||||||
|
| Local workstation | `http://127.0.0.1:8000` |
|
||||||
|
| Remote via tunnel | `http://127.0.0.1:18000` |
|
||||||
|
|
||||||
|
### Orient at session start
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Offline brief — works without hub connection
|
||||||
|
cat .custodian-brief.md
|
||||||
|
|
||||||
|
# Active workstreams for this domain
|
||||||
|
curl -s "http://127.0.0.1:8000/workstreams/?topic_id=36c7421b-c537-4723-bf75-42a3ebc6a1dc&status=active" \
|
||||||
|
| python3 -m json.tool
|
||||||
|
|
||||||
|
# Check inbox
|
||||||
|
curl -s "http://127.0.0.1:8000/messages/?to_agent=markitect-main&unread_only=true" \
|
||||||
|
| python3 -m json.tool
|
||||||
|
```
|
||||||
|
|
||||||
|
Mark a message read:
|
||||||
|
```bash
|
||||||
|
curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
|
||||||
|
-H "Content-Type: application/json" -d '{}'
|
||||||
|
```
|
||||||
|
|
||||||
|
### Log progress (required at session close)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -s -X POST http://127.0.0.1:8000/progress/ \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{
|
||||||
|
"summary": "what was done",
|
||||||
|
"event_type": "note",
|
||||||
|
"author": "codex",
|
||||||
|
"workstream_id": "<uuid>",
|
||||||
|
"task_id": "<uuid>"
|
||||||
|
}'
|
||||||
|
```
|
||||||
|
|
||||||
|
Omit `workstream_id` / `task_id` when not applicable.
|
||||||
|
|
||||||
|
### Update task status
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{"status": "progress"}'
|
||||||
|
# values: wait | todo | progress | done | cancel
|
||||||
|
```
|
||||||
|
|
||||||
|
### Flag a task for human review
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
|
||||||
|
-H "Content-Type: application/json" \
|
||||||
|
-d '{"needs_human": true, "intervention_note": "reason"}'
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Session Protocol
|
||||||
|
|
||||||
|
**Start:**
|
||||||
|
1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
|
||||||
|
2. Check inbox: `GET /messages/?to_agent=markitect-main&unread_only=true`; mark read
|
||||||
|
3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
|
||||||
|
4. Check human-needed tasks: `GET /tasks/?needs_human=true`
|
||||||
|
|
||||||
|
**During work:**
|
||||||
|
- Update task statuses in workplan files as tasks progress
|
||||||
|
- Record significant decisions via `POST /decisions/`
|
||||||
|
|
||||||
|
**Close:**
|
||||||
|
1. Update workplan file task statuses to reflect progress
|
||||||
|
2. Log: `POST /progress/` with a summary of what changed
|
||||||
|
3. Note for the custodian operator: after workplan file changes, run from
|
||||||
|
`~/state-hub`:
|
||||||
|
```bash
|
||||||
|
make fix-consistency REPO=markitect-main
|
||||||
|
```
|
||||||
|
This syncs task status from files into the hub DB.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Credential and access routing
|
||||||
|
|
||||||
|
**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
|
||||||
|
for inference. Run this check **before** requesting secrets, API keys, SSH access,
|
||||||
|
login tokens, or database passwords — in any repo, not only `ops-warden`.
|
||||||
|
|
||||||
|
ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
|
||||||
|
other credential need belongs to another subsystem. **Do not** message
|
||||||
|
`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
|
||||||
|
|
||||||
|
### Lookup (do this first)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
warden route find "<describe your need>" --json
|
||||||
|
warden route show <catalog-id> --json
|
||||||
|
```
|
||||||
|
|
||||||
|
Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
|
||||||
|
|
||||||
|
| Agent runtime | How to orient |
|
||||||
|
| --- | --- |
|
||||||
|
| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=markitect-main` is for coordination, not secret vending |
|
||||||
|
| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
|
||||||
|
| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
|
||||||
|
|
||||||
|
### Quick routing table
|
||||||
|
|
||||||
|
| I need… | Owner | ops-warden executes? |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
|
||||||
|
| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
|
||||||
|
| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
|
||||||
|
| Authorization decision | flex-auth | No — route only |
|
||||||
|
| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
|
||||||
|
| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
|
||||||
|
|
||||||
|
### Anti-patterns (do not do these)
|
||||||
|
|
||||||
|
- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
|
||||||
|
- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
|
||||||
|
- Pasting secrets into Git, State Hub, workplans, logs, or chat
|
||||||
|
|
||||||
|
### Other capabilities (reuse-surface)
|
||||||
|
|
||||||
|
Non-credential capabilities are usually discovered through **reuse-surface** federation
|
||||||
|
(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
|
||||||
|
every repo's agent instructions because it is high-frequency, high-risk, and easy to
|
||||||
|
get wrong.
|
||||||
|
|
||||||
|
**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
|
||||||
|
|
||||||
|
<!-- REPO-AGENTS-EXTENSIONS -->
|
||||||
|
<!-- Append repo-specific agent instructions below this marker.
|
||||||
|
The state-hub template sync preserves content after this line. -->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Workplan Convention (ADR-001)
|
||||||
|
|
||||||
|
Work items originate as files in this repo — not in the hub. The hub is a
|
||||||
|
read/cache/index layer that rebuilds from files.
|
||||||
|
|
||||||
|
**File location:** `workplans/MARKITECT-WP-NNNN-<slug>.md`
|
||||||
|
|
||||||
|
**Archived location:** finished workplans may move to
|
||||||
|
`workplans/archived/YYMMDD-MARKITECT-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
|
||||||
|
the completion/archive date; the frontmatter `id` does not change.
|
||||||
|
|
||||||
|
**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
|
||||||
|
`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
|
||||||
|
this only for low-risk work completed directly; create a normal workplan for
|
||||||
|
anything needing analysis, design, approval, dependencies, or multiple phases.
|
||||||
|
|
||||||
|
**Frontmatter:**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
id: MARKITECT-WP-NNNN
|
||||||
|
type: workplan
|
||||||
|
title: "..."
|
||||||
|
domain: communication
|
||||||
|
repo: markitect-main
|
||||||
|
status: proposed | ready | active | blocked | backlog | finished | archived
|
||||||
|
owner: codex
|
||||||
|
topic_slug: ...
|
||||||
|
created: "YYYY-MM-DD"
|
||||||
|
updated: "YYYY-MM-DD"
|
||||||
|
state_hub_workstream_id: "<uuid>" # written by fix-consistency — do not edit
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
Use `proposed` for a new draft, `ready` after review against current repo
|
||||||
|
state, and `finished` after implementation. `stalled` and `needs_review` are
|
||||||
|
derived health labels, not frontmatter statuses.
|
||||||
|
|
||||||
|
**Task block format** (one per `##` section):
|
||||||
|
|
||||||
|
```
|
||||||
|
## Task Title
|
||||||
|
|
||||||
|
` ` `task
|
||||||
|
id: MARKITECT-WP-NNNN-T01
|
||||||
|
status: wait | todo | progress | done | cancel
|
||||||
|
priority: high | medium | low
|
||||||
|
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit
|
||||||
|
` ` `
|
||||||
|
|
||||||
|
Task description text.
|
||||||
|
```
|
||||||
|
|
||||||
|
Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
|
||||||
|
|
||||||
|
To create a new workplan:
|
||||||
|
1. Write the file following the format above
|
||||||
|
2. Notify the custodian operator to run `make fix-consistency REPO=markitect-main`
|
||||||
|
(or send a message to the hub agent via `POST /messages/`)
|
||||||
12
CLAUDE.md
Normal file
12
CLAUDE.md
Normal file
@@ -0,0 +1,12 @@
|
|||||||
|
# Markitect Main — Claude Code Instructions
|
||||||
|
|
||||||
|
@SCOPE.md
|
||||||
|
@.claude/rules/repo-identity.md
|
||||||
|
@.claude/rules/session-protocol.md
|
||||||
|
@.claude/rules/first-session.md
|
||||||
|
@.claude/rules/workplan-convention.md
|
||||||
|
@.claude/rules/stack-and-commands.md
|
||||||
|
@.claude/rules/architecture.md
|
||||||
|
@.claude/rules/repo-boundary.md
|
||||||
|
@.claude/rules/credential-routing.md
|
||||||
|
@.claude/rules/agents.md
|
||||||
@@ -457,7 +457,7 @@ Sister projects can reuse these capabilities directly:
|
|||||||
Install capabilities via local file references:
|
Install capabilities via local file references:
|
||||||
```toml
|
```toml
|
||||||
[project.dependencies]
|
[project.dependencies]
|
||||||
release-management = {path = "../markitect_project/capabilities/release-management"}
|
release-management = {path = "../markitect-main/capabilities/release-management"}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Shared Infrastructure
|
### Shared Infrastructure
|
||||||
|
|||||||
129
SCOPE.md
Normal file
129
SCOPE.md
Normal file
@@ -0,0 +1,129 @@
|
|||||||
|
# SCOPE
|
||||||
|
|
||||||
|
> This file helps you quickly understand what this repository is about,
|
||||||
|
> when it is relevant, and when it is not.
|
||||||
|
> It is intentionally lightweight and may be incomplete.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## One-liner
|
||||||
|
|
||||||
|
Intelligent markdown engine and information management platform — treats documents as structured, queryable information spaces with schema validation, transclusion, LLM-driven evaluation, and infospace lifecycle management.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Core Idea
|
||||||
|
|
||||||
|
MarkiTect turns fragmented knowledge (scattered docs, chats, notes) into structured, versioned, reusable artifacts. The core abstraction is an **infospace**: a curated collection of typed entities (concepts, mechanisms, observations) governed by a YAML config, validated against schemas, and evaluated for quality across five dimensions. The platform automates generation, validation, and transformation at scale, delegating domain-level judgment to LLMs while Python handles structure and evaluation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## In Scope
|
||||||
|
|
||||||
|
- Parse, validate, and analyze markdown documents against schemas
|
||||||
|
- Generate schemas from example documents; enforce naming convention `{domain}-schema-v{major}.{minor}.md`
|
||||||
|
- Infospace lifecycle: create, populate, evaluate (per-entity + collection quality scores), compose, export
|
||||||
|
- Transclusion: embed content from one document into another, maintaining single source of truth
|
||||||
|
- LLM-driven prompt execution with dependency resolution and quality gates
|
||||||
|
- Relationship graph export (Mermaid, DOT) and analysis (networkx, FCA)
|
||||||
|
- Batch document processing; CLI (`markitect <command>`) and programmatic API
|
||||||
|
- Rendering: markdown → interactive HTML via plugin system (testdrive-jsui)
|
||||||
|
- Asset management (image embedding, resource handling)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- Visual/WYSIWYG editing (markdown-first, text-based workflows only)
|
||||||
|
- Real-time collaborative editing (git-based versioning instead)
|
||||||
|
- Financial transactions or external payment integration
|
||||||
|
- Making domain-level judgments in Python code (delegated to LLM via prompt templates)
|
||||||
|
- Storing secrets or credentials in plaintext
|
||||||
|
- Full GraphQL API (structure exists but not fully implemented)
|
||||||
|
- Vendor-specific integrations or lock-in
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Relevant When
|
||||||
|
|
||||||
|
- Managing large document sets (hundreds to thousands) needing consistent structure and validation
|
||||||
|
- Building or maintaining institutional knowledge bases, technical documentation, or canon releases
|
||||||
|
- Automating document generation from schemas or templates
|
||||||
|
- Tracking relationships and dependencies between knowledge artifacts
|
||||||
|
- Needing programmatic access to document structure (beyond file reading)
|
||||||
|
- Applying quality evaluation to a structured concept collection
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Not Relevant When
|
||||||
|
|
||||||
|
- Working with a handful of simple, unrelated documents
|
||||||
|
- Visual editor required
|
||||||
|
- Exclusively non-markdown source formats (PDF/Word need conversion first)
|
||||||
|
- No consistency, validation, or automation needed
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Current State
|
||||||
|
|
||||||
|
- Status: active (v0.13.0-dev, ~90 commits ahead of release)
|
||||||
|
- Implementation: substantial — core modules mature (CLI, parsing, schema management, prompt execution, infospace); infospace S3 close-out in progress; LLM adapter extracted to standalone `llm-connect` package
|
||||||
|
- Stability: stable core; plugin system and infospace tooling evolving; 200+ CHANGELOG entries since v0.6.0
|
||||||
|
- Usage: active personal development; examples with 988 entities and full evaluation pipeline
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## How It Fits
|
||||||
|
|
||||||
|
- Upstream dependencies: `llm-connect` (LLM adapter library, extracted), `testdrive-jsui` (rendering plugin submodule), `markitect-utils` (utility library)
|
||||||
|
- Downstream consumers: Custodian — MarkiTect is the knowledge artifact platform in the canonical dependency order (Railiance → **Markitect** → Coulomb.social → Personhood/Foerster → Custodian)
|
||||||
|
- Often used with: the-custodian (state hub tracks markitect domain workstreams), kaizen-agentic (project-management agent for session workflow)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Terminology
|
||||||
|
|
||||||
|
- Preferred terms: infospace, topic, discipline, entity, evaluation, viability, transclusion, schema, quality gates
|
||||||
|
- Also known as: "markitect", "the markdown engine"
|
||||||
|
- Potentially confusing terms: "topic" = the subject matter an infospace explains (not a chat thread); "discipline" = a reusable framework of concepts (itself a viable infospace); "infospace" ≠ filesystem directory (it's a curated conceptual collection with explicit quality thresholds)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Related / Overlapping
|
||||||
|
|
||||||
|
- `llm-connect` — standalone LLM adapter extracted from MarkiTect (dependency)
|
||||||
|
- `the-custodian` — tracks markitect workstreams; custodian canon includes a markitect domain charter
|
||||||
|
- `marki-docx` — separate repo (on tegwick machine); relationship: docx export capability for MarkiTect artifacts
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Provided Capabilities
|
||||||
|
|
||||||
|
```capability
|
||||||
|
type: documentation
|
||||||
|
title: Structured document validation and schema management
|
||||||
|
description: Parse, validate, and enforce schemas on markdown documents — generate schemas from examples, validate entity collections, report naming convention compliance.
|
||||||
|
keywords: [markdown, schema, validation, document, structure, linting]
|
||||||
|
```
|
||||||
|
|
||||||
|
```capability
|
||||||
|
type: documentation
|
||||||
|
title: Infospace lifecycle management
|
||||||
|
description: Create, populate, evaluate (quality scores), compose, and export curated knowledge collections (infospaces) with transclusion and relationship graph analysis.
|
||||||
|
keywords: [infospace, knowledge, curation, evaluation, transclusion, quality, graph]
|
||||||
|
```
|
||||||
|
|
||||||
|
```capability
|
||||||
|
type: data
|
||||||
|
title: LLM-driven knowledge artifact generation
|
||||||
|
description: Execute prompts with dependency resolution and quality gates to generate typed entities — concepts, mechanisms, observations — at scale from schemas and templates.
|
||||||
|
keywords: [llm, generation, prompt, entity, artifact, knowledge, automation]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Getting Oriented
|
||||||
|
|
||||||
|
- Start with: `CLAUDE.md` (dev commands, LLM config, infospace lifecycle), `INTRODUCTION.md` (use cases, philosophy)
|
||||||
|
- Key files / directories: `markitect/cli.py` (CLI entry point), `markitect/infospace/` (primary active area), `markitect/prompts/` (LLM execution), `roadmap/` (6 active planning tracks), `examples/infospace-with-history/` (988-entity reference implementation)
|
||||||
|
- Entry points: `markitect --help`; `markitect infospace --help`; `pytest tests/unit/` (inner TDD loop)
|
||||||
@@ -15,7 +15,7 @@ You are responsible for:
|
|||||||
|
|
||||||
### Directory Structure
|
### Directory Structure
|
||||||
```
|
```
|
||||||
markitect_project/
|
markitect-main/
|
||||||
├── Makefile # Main project Makefile
|
├── Makefile # Main project Makefile
|
||||||
├── scripts/
|
├── scripts/
|
||||||
│ └── capability_discovery.mk # Auto-discovery and delegation system
|
│ └── capability_discovery.mk # Auto-discovery and delegation system
|
||||||
|
|||||||
@@ -7,7 +7,7 @@ detachment:
|
|||||||
capability_name: issue-facade
|
capability_name: issue-facade
|
||||||
capability_family: issue-tracking
|
capability_family: issue-tracking
|
||||||
integration_pattern: capabilities-directory
|
integration_pattern: capabilities-directory
|
||||||
original_location: /home/worsch/markitect_project/capabilities/issue-facade
|
original_location: /home/worsch/markitect-main/capabilities/issue-facade
|
||||||
|
|
||||||
capability_metadata:
|
capability_metadata:
|
||||||
spec_file: CAPABILITY-issue-tracking.yaml
|
spec_file: CAPABILITY-issue-tracking.yaml
|
||||||
@@ -17,23 +17,23 @@ capability_metadata:
|
|||||||
|
|
||||||
integration_details:
|
integration_details:
|
||||||
parent_project: capabilities
|
parent_project: capabilities
|
||||||
parent_path: /home/worsch/markitect_project/capabilities
|
parent_path: /home/worsch/markitect-main/capabilities
|
||||||
|
|
||||||
re_integration_guide: |
|
re_integration_guide: |
|
||||||
To re-integrate this capability using the new architecture:
|
To re-integrate this capability using the new architecture:
|
||||||
|
|
||||||
# Option 1: Git submodule (recommended)
|
# Option 1: Git submodule (recommended)
|
||||||
cd /home/worsch/markitect_project/capabilities
|
cd /home/worsch/markitect-main/capabilities
|
||||||
git submodule add <repo-url> _issue-facade
|
git submodule add <repo-url> _issue-facade
|
||||||
pip install -e _issue-facade/
|
pip install -e _issue-facade/
|
||||||
|
|
||||||
# Option 2: Clone directly
|
# Option 2: Clone directly
|
||||||
cd /home/worsch/markitect_project/capabilities
|
cd /home/worsch/markitect-main/capabilities
|
||||||
git clone <repo-url> _issue-facade
|
git clone <repo-url> _issue-facade
|
||||||
pip install -e _issue-facade/
|
pip install -e _issue-facade/
|
||||||
|
|
||||||
# Option 3: Copy into project
|
# Option 3: Copy into project
|
||||||
cd /home/worsch/markitect_project/capabilities
|
cd /home/worsch/markitect-main/capabilities
|
||||||
cp -r /path/to/issue-facade _issue-facade
|
cp -r /path/to/issue-facade _issue-facade
|
||||||
pip install -e _issue-facade/
|
pip install -e _issue-facade/
|
||||||
|
|
||||||
|
|||||||
@@ -8,7 +8,7 @@ This test module validates outline mode schema generation improvements including
|
|||||||
- Content instruction integration
|
- Content instruction integration
|
||||||
- End-to-end workflow from example document to generated drafts
|
- End-to-end workflow from example document to generated drafts
|
||||||
|
|
||||||
Created for Issue #46: https://gitea.coulomb.social/coulomb/markitect_project/issues/46
|
Created for Issue #46: https://gitea.coulomb.social/coulomb/markitect-main/issues/46
|
||||||
"""
|
"""
|
||||||
|
|
||||||
import pytest
|
import pytest
|
||||||
|
|||||||
@@ -209,7 +209,7 @@ tests/
|
|||||||
## 🎯 Detailed File Structure After Migration
|
## 🎯 Detailed File Structure After Migration
|
||||||
|
|
||||||
```
|
```
|
||||||
markitect_project/
|
markitect-main/
|
||||||
├── capabilities/
|
├── capabilities/
|
||||||
│ └── release-management/
|
│ └── release-management/
|
||||||
│ ├── README.md ✅ CREATED
|
│ ├── README.md ✅ CREATED
|
||||||
|
|||||||
@@ -162,7 +162,7 @@ clean_before_build = true
|
|||||||
[tool.release-management.registries.gitea]
|
[tool.release-management.registries.gitea]
|
||||||
url = "http://92.205.130.254:32166"
|
url = "http://92.205.130.254:32166"
|
||||||
owner = "coulomb"
|
owner = "coulomb"
|
||||||
repo = "markitect_project"
|
repo = "markitect-main"
|
||||||
auth_token_env = "GITEA_API_TOKEN"
|
auth_token_env = "GITEA_API_TOKEN"
|
||||||
|
|
||||||
[tool.release-management.registries.pypi]
|
[tool.release-management.registries.pypi]
|
||||||
|
|||||||
@@ -141,7 +141,7 @@ make release-publish VERSION=0.8.0
|
|||||||
## Registry Information
|
## Registry Information
|
||||||
|
|
||||||
- **Gitea URL**: http://92.205.130.254:32166
|
- **Gitea URL**: http://92.205.130.254:32166
|
||||||
- **Repository**: coulomb/markitect_project
|
- **Repository**: coulomb/markitect-main
|
||||||
- **PyPI Registry URL**: http://92.205.130.254:32166/api/packages/coulomb/pypi
|
- **PyPI Registry URL**: http://92.205.130.254:32166/api/packages/coulomb/pypi
|
||||||
- **Package List URL**: http://92.205.130.254:32166/api/v1/packages/coulomb
|
- **Package List URL**: http://92.205.130.254:32166/api/v1/packages/coulomb
|
||||||
|
|
||||||
|
|||||||
@@ -8,7 +8,7 @@
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# ❌ WRONG - Don't edit capability files from main repo
|
# ❌ WRONG - Don't edit capability files from main repo
|
||||||
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
|
cd /home/worsch/markitect-main/capabilities/testdrive-jsui
|
||||||
vim src/testdrive_jsui/core.py # DON'T DO THIS!
|
vim src/testdrive_jsui/core.py # DON'T DO THIS!
|
||||||
|
|
||||||
# ✅ CORRECT - Use separate Claude instance/session
|
# ✅ CORRECT - Use separate Claude instance/session
|
||||||
@@ -29,7 +29,7 @@ cd /path/to/work/testdrive-jsui
|
|||||||
|
|
||||||
| Session | Purpose | Location |
|
| Session | Purpose | Location |
|
||||||
|---------|---------|----------|
|
|---------|---------|----------|
|
||||||
| **Main Repo** | Integration, configuration | `/home/worsch/markitect_project` |
|
| **Main Repo** | Integration, configuration | `/home/worsch/markitect-main` |
|
||||||
| **Capability** | Feature development, bugs | Separate clone or `capabilities/capability-name` |
|
| **Capability** | Feature development, bugs | Separate clone or `capabilities/capability-name` |
|
||||||
|
|
||||||
**Why?** Prevents accidental cross-contamination and respects repository boundaries.
|
**Why?** Prevents accidental cross-contamination and respects repository boundaries.
|
||||||
@@ -40,7 +40,7 @@ cd /path/to/work/testdrive-jsui
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# After pushing changes to capability repo
|
# After pushing changes to capability repo
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
git submodule update --remote capabilities/testdrive-jsui
|
git submodule update --remote capabilities/testdrive-jsui
|
||||||
git add capabilities/testdrive-jsui
|
git add capabilities/testdrive-jsui
|
||||||
git commit -m "chore: update testdrive-jsui to latest"
|
git commit -m "chore: update testdrive-jsui to latest"
|
||||||
@@ -50,7 +50,7 @@ git push
|
|||||||
### Add New Capability
|
### Add New Capability
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
|
|
||||||
# Add as submodule
|
# Add as submodule
|
||||||
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
|
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
|
||||||
@@ -67,7 +67,7 @@ git commit -m "feat: add new-capability submodule"
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Option 1: In submodule directory (careful!)
|
# Option 1: In submodule directory (careful!)
|
||||||
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
|
cd /home/worsch/markitect-main/capabilities/testdrive-jsui
|
||||||
git checkout -b feature-branch
|
git checkout -b feature-branch
|
||||||
# make changes
|
# make changes
|
||||||
git commit -m "feat: new feature"
|
git commit -m "feat: new feature"
|
||||||
@@ -86,7 +86,7 @@ git push origin feature-branch
|
|||||||
### Check Capability Status
|
### Check Capability Status
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
|
|
||||||
# List all capabilities
|
# List all capabilities
|
||||||
make capabilities-list
|
make capabilities-list
|
||||||
|
|||||||
@@ -9,7 +9,7 @@ MarkiTect is a markdown processing toolkit with transclusion, schema validation,
|
|||||||
## Current Directory Structure
|
## Current Directory Structure
|
||||||
|
|
||||||
```
|
```
|
||||||
markitect_project/
|
markitect-main/
|
||||||
├── markitect/ # Main package
|
├── markitect/ # Main package
|
||||||
│ ├── [34 root-level .py files] # Core functionality (see below)
|
│ ├── [34 root-level .py files] # Core functionality (see below)
|
||||||
│ ├── assets/ # Asset discovery, management, caching (21 files)
|
│ ├── assets/ # Asset discovery, management, caching (21 files)
|
||||||
|
|||||||
@@ -8,7 +8,7 @@ MarkiTect uses a **capabilities-based architecture** where functionality is orga
|
|||||||
|
|
||||||
### 1. **Separation of Concerns**
|
### 1. **Separation of Concerns**
|
||||||
|
|
||||||
**Critical Rule:** The main repository (`markitect_project`) **MUST NOT** directly modify capability code.
|
**Critical Rule:** The main repository (`markitect-main`) **MUST NOT** directly modify capability code.
|
||||||
|
|
||||||
- ✅ **DO**: Use capabilities as dependencies
|
- ✅ **DO**: Use capabilities as dependencies
|
||||||
- ✅ **DO**: Configure capabilities through documented interfaces
|
- ✅ **DO**: Configure capabilities through documented interfaces
|
||||||
@@ -28,7 +28,7 @@ MarkiTect uses a **capabilities-based architecture** where functionality is orga
|
|||||||
Capabilities are integrated as **git submodules**, not regular directories:
|
Capabilities are integrated as **git submodules**, not regular directories:
|
||||||
|
|
||||||
```
|
```
|
||||||
markitect_project/
|
markitect-main/
|
||||||
├── .gitmodules # Submodule configuration
|
├── .gitmodules # Submodule configuration
|
||||||
├── capabilities/
|
├── capabilities/
|
||||||
│ ├── testdrive-jsui/ # Git submodule → separate repo
|
│ ├── testdrive-jsui/ # Git submodule → separate repo
|
||||||
@@ -80,8 +80,8 @@ engine.render_document(content, mode='edit', config=config)
|
|||||||
|
|
||||||
#### Main Repository Session
|
#### Main Repository Session
|
||||||
```bash
|
```bash
|
||||||
# In markitect_project/
|
# In markitect-main/
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
|
|
||||||
# Main repo tasks:
|
# Main repo tasks:
|
||||||
# - Integrate capabilities
|
# - Integrate capabilities
|
||||||
@@ -93,7 +93,7 @@ cd /home/worsch/markitect_project
|
|||||||
#### Capability Session
|
#### Capability Session
|
||||||
```bash
|
```bash
|
||||||
# In capability repository
|
# In capability repository
|
||||||
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
|
cd /home/worsch/markitect-main/capabilities/testdrive-jsui
|
||||||
|
|
||||||
# OR clone separately
|
# OR clone separately
|
||||||
git clone http://gitea/coulomb/testdrive-jsui.git
|
git clone http://gitea/coulomb/testdrive-jsui.git
|
||||||
@@ -122,7 +122,7 @@ cd testdrive-jsui
|
|||||||
|
|
||||||
2. **Update main project** (different Claude instance)
|
2. **Update main project** (different Claude instance)
|
||||||
```bash
|
```bash
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
git submodule update --remote capabilities/testdrive-jsui
|
git submodule update --remote capabilities/testdrive-jsui
|
||||||
git commit -m "chore: update testdrive-jsui submodule"
|
git commit -m "chore: update testdrive-jsui submodule"
|
||||||
```
|
```
|
||||||
@@ -139,7 +139,7 @@ When a capability releases a new version:
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# In main repo
|
# In main repo
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
|
|
||||||
# Update specific capability
|
# Update specific capability
|
||||||
cd capabilities/testdrive-jsui
|
cd capabilities/testdrive-jsui
|
||||||
@@ -160,7 +160,7 @@ git commit -am "chore: update all capabilities"
|
|||||||
# http://gitea/coulomb/new-capability
|
# http://gitea/coulomb/new-capability
|
||||||
|
|
||||||
# 2. Add as submodule to main repo
|
# 2. Add as submodule to main repo
|
||||||
cd /home/worsch/markitect_project
|
cd /home/worsch/markitect-main
|
||||||
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
|
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
|
||||||
|
|
||||||
# 3. Add dependency to pyproject.toml
|
# 3. Add dependency to pyproject.toml
|
||||||
@@ -324,7 +324,7 @@ def test_testdrive_jsui_integration():
|
|||||||
1. **Create separate git repo**
|
1. **Create separate git repo**
|
||||||
```bash
|
```bash
|
||||||
cd /tmp
|
cd /tmp
|
||||||
cp -r markitect_project/capabilities/capability-name capability-name
|
cp -r markitect-main/capabilities/capability-name capability-name
|
||||||
cd capability-name
|
cd capability-name
|
||||||
git init
|
git init
|
||||||
git add .
|
git add .
|
||||||
@@ -335,7 +335,7 @@ def test_testdrive_jsui_integration():
|
|||||||
|
|
||||||
2. **Remove from main repo**
|
2. **Remove from main repo**
|
||||||
```bash
|
```bash
|
||||||
cd markitect_project
|
cd markitect-main
|
||||||
git rm -rf capabilities/capability-name
|
git rm -rf capabilities/capability-name
|
||||||
git commit -m "chore: remove capability-name for submodule conversion"
|
git commit -m "chore: remove capability-name for submodule conversion"
|
||||||
```
|
```
|
||||||
|
|||||||
203
docs/composition-guide.md
Normal file
203
docs/composition-guide.md
Normal file
@@ -0,0 +1,203 @@
|
|||||||
|
# Infospace Composition Guide
|
||||||
|
|
||||||
|
One completed, viable infospace can be reused as a **discipline** for
|
||||||
|
another infospace — a lens applied to a different topic. This guide
|
||||||
|
explains how composition works and walks through the live
|
||||||
|
`examples/supply-chain-vsm/` reference.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What composition means
|
||||||
|
|
||||||
|
An **infospace** is a directory of typed entities governed by
|
||||||
|
`infospace.yaml`. Its entities and relations describe a specific topic
|
||||||
|
(for example, Adam Smith's *Wealth of Nations*).
|
||||||
|
|
||||||
|
A **discipline** is an infospace declared as a reusable analytical
|
||||||
|
framework by another infospace. When infospace B binds infospace A as a
|
||||||
|
discipline:
|
||||||
|
|
||||||
|
1. B's entities can reference A's entities in `## WoN Concept` (or
|
||||||
|
equivalent) sections.
|
||||||
|
2. Properties A has already computed on its entities — such as VSM system
|
||||||
|
placement — become available to B by transitivity through the mapping.
|
||||||
|
3. B can impose its own viability thresholds independently of A's. The two
|
||||||
|
infospaces each pass or fail viability on their own terms.
|
||||||
|
|
||||||
|
The binding is declarative: a relative path in `infospace.yaml` plus a
|
||||||
|
display name. No code. No import. The discipline is looked up on disk at
|
||||||
|
the declared path when B's commands run.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The viability pre-condition
|
||||||
|
|
||||||
|
Binding a non-viable infospace as a discipline is a mistake: a framework
|
||||||
|
that fails its own thresholds is not a stable reference frame. Before
|
||||||
|
binding, confirm the candidate discipline is viable:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd examples/infospace-with-history
|
||||||
|
markitect infospace viability
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Metric Value Threshold Status
|
||||||
|
---------------------------------------------------------------
|
||||||
|
redundancy_ratio 0.0061 max=0.1 PASS
|
||||||
|
coverage_ratio 0.6190 min=0.4 PASS
|
||||||
|
coherence_components 0.0000 max=3 PASS
|
||||||
|
consistency_cycles 0.0000 max=0 PASS
|
||||||
|
granularity_entropy 2.6748 min=1.0 PASS
|
||||||
|
per_entity_mean 3.9556 min=3.5 PASS
|
||||||
|
|
||||||
|
Viable: YES (6/6 thresholds met)
|
||||||
|
```
|
||||||
|
|
||||||
|
If the discipline is not viable, fix it first (see
|
||||||
|
`examples/infospace-with-history/docs/advanced-usage.md` §4 for triaging
|
||||||
|
low scorers).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example — how `supply-chain-vsm` binds WoN
|
||||||
|
|
||||||
|
The supply-chain infospace declares WoN as a discipline in its
|
||||||
|
`infospace.yaml`:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
topic:
|
||||||
|
name: "Modern Supply Chain Management"
|
||||||
|
domain: "Operations Management"
|
||||||
|
sources: artifacts/sources/
|
||||||
|
|
||||||
|
disciplines:
|
||||||
|
- name: "Wealth of Nations"
|
||||||
|
path: ../infospace-with-history
|
||||||
|
```
|
||||||
|
|
||||||
|
The binding is a **relative path**, so the two infospaces travel together
|
||||||
|
(they can be moved as a pair without breaking the link).
|
||||||
|
|
||||||
|
Verify the binding resolves and the discipline is viable:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd examples/supply-chain-vsm
|
||||||
|
markitect infospace disciplines
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Name Entities Viable Path
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
Wealth of Nations 988 YES ../infospace-with-history
|
||||||
|
```
|
||||||
|
|
||||||
|
Each supply-chain entity then carries a `## WoN Concept` section
|
||||||
|
mapping it to exactly one WoN entity. The consolidated mapping files
|
||||||
|
(`output/mappings/*-mappings.md`) record the pairing, rationale, and a
|
||||||
|
conceptual-continuity rating (Strong / Moderate / Weak):
|
||||||
|
|
||||||
|
| Supply Chain Entity | WoN Concept | Strength | VSM |
|
||||||
|
|------------------------------|----------------------------------|----------|-------|
|
||||||
|
| Demand Signal | Effectual Demand | Strong | S2 |
|
||||||
|
| Vendor-Managed Inventory | Division of Labour | Strong | S1/S2 |
|
||||||
|
| Just-in-Time Inventory | Circulating Capital | Strong | S1/S3 |
|
||||||
|
| Bullwhip Effect | Natural Price as Central Price | Moderate | S2 |
|
||||||
|
| Safety Stock | Accumulation of Stock | Moderate | S3 |
|
||||||
|
|
||||||
|
Because each WoN entity already has a VSM system placement (S1–S5), the
|
||||||
|
supply-chain entities inherit a VSM position by transitivity through
|
||||||
|
their mapping — without supply-chain-vsm needing its own VSM reference.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Creating a new infospace that binds an existing one
|
||||||
|
|
||||||
|
Step-by-step, using WoN as the discipline for a hypothetical "Modern
|
||||||
|
Monetary Policy" infospace:
|
||||||
|
|
||||||
|
### 1. Start from the target topic
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir -p examples/monetary-policy/artifacts/sources
|
||||||
|
cd examples/monetary-policy
|
||||||
|
markitect infospace init
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Declare the discipline in `infospace.yaml`
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
topic:
|
||||||
|
name: "Modern Monetary Policy"
|
||||||
|
domain: "Macroeconomics"
|
||||||
|
sources: artifacts/sources/
|
||||||
|
|
||||||
|
disciplines:
|
||||||
|
- name: "Wealth of Nations"
|
||||||
|
path: ../infospace-with-history
|
||||||
|
```
|
||||||
|
|
||||||
|
Alternatively, bind imperatively after `init`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
markitect infospace bind-discipline ../infospace-with-history --name "Wealth of Nations"
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Set your own viability thresholds
|
||||||
|
|
||||||
|
Copy the `viability:` block from a reference infospace and tune the
|
||||||
|
numbers to the scale and maturity of your topic. A smaller infospace
|
||||||
|
(50 entities, not 988) may need laxer `coverage_ratio` and stricter
|
||||||
|
`redundancy_ratio`.
|
||||||
|
|
||||||
|
### 4. Verify the binding
|
||||||
|
|
||||||
|
```bash
|
||||||
|
markitect infospace disciplines
|
||||||
|
```
|
||||||
|
|
||||||
|
If `Viable` is `NO`, stop and fix the discipline before continuing.
|
||||||
|
|
||||||
|
### 5. Reference discipline entities in your own entities
|
||||||
|
|
||||||
|
For each entity in the new infospace, add a `## <Discipline> Concept`
|
||||||
|
section that names the WoN entity the concept maps to, plus a rationale.
|
||||||
|
The exact section heading is configured per schema — see
|
||||||
|
`schemas/won-mapping-schema-v1.0.md` in `supply-chain-vsm` for the
|
||||||
|
template used there.
|
||||||
|
|
||||||
|
### 6. Run checks and evaluate
|
||||||
|
|
||||||
|
```bash
|
||||||
|
markitect infospace check
|
||||||
|
markitect infospace evaluate --provider openrouter
|
||||||
|
markitect infospace eval-summary --update-metrics
|
||||||
|
markitect infospace viability
|
||||||
|
```
|
||||||
|
|
||||||
|
The new infospace passes or fails viability independently of WoN.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Why composition, not inclusion?
|
||||||
|
|
||||||
|
An alternative would be to copy WoN entities directly into the target
|
||||||
|
infospace. Composition avoids that by design:
|
||||||
|
|
||||||
|
- **One source of truth** — if WoN is refined, every infospace that binds
|
||||||
|
it picks up the improvement on the next run without a sync step.
|
||||||
|
- **Separation of concerns** — each infospace owns its own schema,
|
||||||
|
thresholds, and entity set. Changing the target topic cannot pollute
|
||||||
|
the discipline.
|
||||||
|
- **Bounded dependency** — the binding is a path, so the coupling is
|
||||||
|
visible in one place (`infospace.yaml`) and easy to remove.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## See also
|
||||||
|
|
||||||
|
- `examples/supply-chain-vsm/README.md` — the full reference composition.
|
||||||
|
- `examples/supply-chain-vsm/output/mappings/` — consolidated mapping
|
||||||
|
files showing the rationale and strength rating for each pairing.
|
||||||
|
- `examples/infospace-with-history/docs/advanced-usage.md` — patterns for
|
||||||
|
maintaining the discipline once it is in use.
|
||||||
141
docs/successor-gap-assessment.md
Normal file
141
docs/successor-gap-assessment.md
Normal file
@@ -0,0 +1,141 @@
|
|||||||
|
# markitect-main → Successor Repos: Gap Assessment
|
||||||
|
|
||||||
|
**Date:** 2026-05-23
|
||||||
|
**Author:** Claude (custodian session)
|
||||||
|
**Status:** Draft — awaiting Bernd's decisions on items A/B/C below
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Bernd is retiring `markitect-main` and has transferred most functionality to
|
||||||
|
sibling repos. This document identifies what was provided by `markitect-main`
|
||||||
|
that is **not addressed** in those successors, and flags candidates that may
|
||||||
|
not fit any successor's intent.
|
||||||
|
|
||||||
|
## Successor Ecosystem (5 repos, not 3)
|
||||||
|
|
||||||
|
| Repo | Role |
|
||||||
|
|---|---|
|
||||||
|
| `markitect-tool` | Markdown syntax layer + structured-document primitives; defines source-adapter and render-adapter contracts. CLI: `mkt`. |
|
||||||
|
| `kontextual-engine` | Headless knowledge operations engine: artifacts, collections, persistence, relationships, workflow runs/manifests, query, quality/assessment, API. |
|
||||||
|
| `infospace-bench` | Application layer — concrete infospaces, evaluation methodology, reference pilots. |
|
||||||
|
| `markitect-filter` | Source-format ingestion adapters (`source.epub3`, `source.pdf`) implementing the markitect-tool source-adapter contract. |
|
||||||
|
| `markitect-quarkdown` | Render/export adapter — implements the markitect-tool render-adapter contract via Quarkdown. |
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
Analysis is grounded in each successor's own assessment docs (recent, May 2026):
|
||||||
|
|
||||||
|
- `markitect-tool/docs/markitect-main-scope-assessment.md`
|
||||||
|
- `kontextual-engine/docs/markitect-main-scope-assessment.md`
|
||||||
|
- `kontextual-engine/docs/system-layer-extraction-inventory.md`
|
||||||
|
- `kontextual-engine/docs/system-layer-migration-backlog.md`
|
||||||
|
- `infospace-bench/docs/markitect-main-scope-assessment.md`
|
||||||
|
- `infospace-bench/docs/legacy-infospace-feature-inventory.md`
|
||||||
|
- `infospace-bench/docs/replacement-acceptance-matrix.md`
|
||||||
|
|
||||||
|
Cross-checked against actual `markitect-main` module sizing (Python LOC) and
|
||||||
|
`__init__.py` docstrings.
|
||||||
|
|
||||||
|
**Confidence:** These successor docs are authoritative on *intent*. They have
|
||||||
|
**not** been line-verified to confirm every "reimplement"-classified item
|
||||||
|
actually landed in the successor. Where verification matters, it's flagged.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## A. Doesn't fit any successor's intent — needs a new home or explicit retirement
|
||||||
|
|
||||||
|
These are explicitly pushed away by tool/engine/bench and are unrelated to
|
||||||
|
filter/quarkdown.
|
||||||
|
|
||||||
|
| markitect-main area | LOC | What it is | Status |
|
||||||
|
|---|---|---|---|
|
||||||
|
| `markitect/finance/` | ~8,100 | Cost-tracking system: cost items, period allocation to issues, financial reports, audit trails | **Orphan.** markitect-main's own SCOPE.md lists "financial transactions" as out-of-scope. Belongs with issue/project-ops, not knowledge tooling. |
|
||||||
|
| `issue_tracker/` + `_issue-tracking/` + `.issues/` | ~1,200 | Issue tracking (finance allocates costs to these issues) | **Orphan to the five** — but likely already superseded by the `issue-facade` capability / `use-issues` skill. **Verify before retiring.** |
|
||||||
|
| `markitect/profile/` | ~1,600 | User-profile CRUD, multi-profile, DB-backed | **Orphan.** Unrelated to all five. (Distinct from quarkdown's *render* "profile".) |
|
||||||
|
| `markitect/production/` | ~3,800 | Deployment-readiness validation, cross-platform checks, perf benchmarking | Engine keeps only "structured error/audit *ideas*". Deployment-validation bulk is orphan. |
|
||||||
|
| `tools/`, `services/`, gitea/tddai glue | ~5,500 | Project-ops tooling | Out-of-scope everywhere. |
|
||||||
|
| `markitect/legacy/` + `legacy_compat.py` | ~2,700 | Backward-compat shims | Retire by definition. |
|
||||||
|
|
||||||
|
## B. Rendering / asset / plugin layer — only *partially* covered, real residual gap
|
||||||
|
|
||||||
|
**This is the most consequential gap.** `SCOPE.md` lists "Rendering: markdown
|
||||||
|
→ interactive HTML via plugin system (testdrive-jsui)" as an in-scope
|
||||||
|
capability of markitect-main.
|
||||||
|
|
||||||
|
| Area | LOC | Covered? |
|
||||||
|
|---|---|---|
|
||||||
|
| `markitect/plugins/` (generic processor/formatter/validator/exporter plugin system) | ~8,000 | **No.** tool defines a render-adapter *contract* and an *extension* point, but the general plugin runtime isn't carried. |
|
||||||
|
| `markitect/assets/` (content-addressable asset store, dedup, `.mdpkg` ZIP packaging, symlink handling) + `asset_registry.json` (277 KB) | ~6,000 | **No.** Bench says "leave behind unless a concrete export needs assets." |
|
||||||
|
| Interactive-HTML / testdrive-jsui rendering, `static/`, `themes/`, `templates/document.html`, JS UI | — | **Partial only.** quarkdown covers a *Quarkdown* export path; the interactive-HTML / JS-UI path has no home. |
|
||||||
|
|
||||||
|
**Decision needed:** spin these into a dedicated render/asset repo (sibling to
|
||||||
|
quarkdown), fold the asset store into one of the existing repos, or retire the
|
||||||
|
interactive-HTML path.
|
||||||
|
|
||||||
|
## C. The other "Information Space" lineage — `markitect/spaces/` (~11,000 LOC)
|
||||||
|
|
||||||
|
**Distinct from `markitect/infospace/`** (which infospace-bench inherited).
|
||||||
|
`spaces/` is an older/parallel abstraction with features bench did *not* take:
|
||||||
|
|
||||||
|
- event-driven change tracking & notifications
|
||||||
|
- persistent transclusion context with cross-space references
|
||||||
|
- bidirectional directory synchronization
|
||||||
|
- HTML rendering of spaces with caching/themes
|
||||||
|
|
||||||
|
Engine takes generic persistence concepts and bench takes infospace semantics,
|
||||||
|
but **these specific `spaces/` behaviors (bidirectional sync, event
|
||||||
|
notifications, cross-space transclusion context) aren't mapped anywhere.**
|
||||||
|
|
||||||
|
Likely intended as dead/superseded — but 11k LOC warrants an explicit "retire
|
||||||
|
vs salvage" call.
|
||||||
|
|
||||||
|
## D. Declined-by-design (confirm retirement, don't re-extract)
|
||||||
|
|
||||||
|
| Area | LOC | Disposition |
|
||||||
|
|---|---|---|
|
||||||
|
| `markitect/graphql/` | ~4,000 | All three explicitly declined GraphQL ("evidence of API need, not a commitment"). |
|
||||||
|
| `markitect/query_paradigms/` | ~3,500 | Engine/tool keep the *QueryResult envelope* concept but say "do not port the registry wholesale." |
|
||||||
|
| `markitect/proxy/` | ~870 | Non-markdown→md proxy with checksum/freshness tracking. **Overlaps markitect-filter.** Freshness/staleness-tracking mechanism may be worth checking against bench's deferred "stale-mappings." |
|
||||||
|
| `capabilities/` (top-level) | ~8,300 | Capability-packaging architecture; partially maps to tool (schema generation) but the packaging approach itself isn't carried. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What this means
|
||||||
|
|
||||||
|
The successors are, by their own assessments, **near complete for the
|
||||||
|
in-scope core** (parsing/schema → tool; persistence/workflow → engine;
|
||||||
|
infospace lifecycle → bench; ingestion → filter; one render path →
|
||||||
|
quarkdown). The truly unaddressed functionality is almost entirely the stuff
|
||||||
|
markitect-main accreted **beyond** its stated scope: finance, issue tracking,
|
||||||
|
user profiles, production/deployment validation, the asset/plugin/interactive-HTML
|
||||||
|
rendering stack, and the older `spaces/` abstraction.
|
||||||
|
|
||||||
|
## Decisions for Bernd
|
||||||
|
|
||||||
|
Three live decisions, not a long extraction backlog:
|
||||||
|
|
||||||
|
### Decision 1 — Render/asset stack (Section B)
|
||||||
|
The one with genuine product value left.
|
||||||
|
- **Option 1a:** new repo (sibling to quarkdown) for plugin runtime + asset store + interactive-HTML
|
||||||
|
- **Option 1b:** fold the asset store into an existing repo (most likely markitect-tool, behind a flag); retire interactive-HTML
|
||||||
|
- **Option 1c:** retire the interactive-HTML path entirely; trust quarkdown export as the single render story
|
||||||
|
|
||||||
|
### Decision 2 — `markitect/spaces/` (Section C)
|
||||||
|
- **Option 2a:** salvage bidirectional-sync / event-tracking / cross-space transclusion into engine (engine has the persistence story to support it)
|
||||||
|
- **Option 2b:** retire wholesale as superseded by infospace
|
||||||
|
|
||||||
|
### Decision 3 — Project-ops cluster (Section A: finance + issues + profile)
|
||||||
|
- **Option 3a:** confirm `issue-facade` already replaces `issue_tracker/` + `finance/`; retire both
|
||||||
|
- **Option 3b:** identify a home for any pieces worth keeping
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Suggested verification before deciding
|
||||||
|
|
||||||
|
If verification matters before committing:
|
||||||
|
|
||||||
|
- **For Decision 1:** grep the five repos for any render/asset adapter that already covers the HTML path beyond Quarkdown.
|
||||||
|
- **For Decision 2:** check whether engine's `OperationRun` + collection model can express bidirectional-sync semantics, or whether new primitives would be needed.
|
||||||
|
- **For Decision 3:** confirm whether `issue-facade` truly replaces `issue_tracker/` + `finance/` end-to-end.
|
||||||
|
|
||||||
|
Happy to do any of these focused passes when you're ready to decide.
|
||||||
@@ -117,7 +117,7 @@ This graph enables:
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Ensure MarkiTect is installed
|
# Ensure MarkiTect is installed
|
||||||
cd /path/to/markitect_project
|
cd /path/to/markitect-main
|
||||||
pip install -e .
|
pip install -e .
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -57,7 +57,7 @@ How the example measures against the objectives stated in `README.md`:
|
|||||||
| 9 | No infrastructure changes during experiment | **Violated** | Three infra fixes were required (tasks 1-3 above). Documented as intended. |
|
| 9 | No infrastructure changes during experiment | **Violated** | Three infra fixes were required (tasks 1-3 above). Documented as intended. |
|
||||||
| 10 | Generate task list for infra issues | **Done** | This file. |
|
| 10 | Generate task list for infra issues | **Done** | This file. |
|
||||||
|
|
||||||
## 4. Infospace has no per-chapter git history — OPEN
|
## 4. Infospace has no per-chapter git history — PARTIAL
|
||||||
|
|
||||||
**Objective:** README states "The information space should utilize the option
|
**Objective:** README states "The information space should utilize the option
|
||||||
of keeping changes as git history."
|
of keeping changes as git history."
|
||||||
@@ -69,12 +69,15 @@ archive policy. There is no commit where you can `git diff` to see exactly
|
|||||||
what one chapter contributed to the infospace.
|
what one chapter contributed to the infospace.
|
||||||
**Impact:** Cannot use `git log`, `git diff`, or `git bisect` to trace how
|
**Impact:** Cannot use `git log`, `git diff`, or `git bisect` to trace how
|
||||||
the infospace grew chapter by chapter — the core promise of "with history."
|
the infospace grew chapter by chapter — the core promise of "with history."
|
||||||
**Suggested fix:** Re-run the 7 processed chapters (and remaining 28) using
|
**Progress:** Branch `clean-example-history` was created. Chapters 1-8 have
|
||||||
|
clean per-chapter commits. 27 chapters remain. Example completeness (tasks 4
|
||||||
|
and 7) is deferred; no further action planned.
|
||||||
|
**Suggested fix (original):** Re-run the processed chapters using
|
||||||
`process_chapters.py` without `--no-commit`, on a clean branch or after
|
`process_chapters.py` without `--no-commit`, on a clean branch or after
|
||||||
squashing the current output into a baseline commit. Each chapter gets its
|
squashing the current output into a baseline commit. Each chapter gets its
|
||||||
own commit via `_git_commit_chapter()`.
|
own commit via `_git_commit_chapter()`.
|
||||||
|
|
||||||
## 5. Prompt files are regenerated as a side-effect of DB rebuild — OPEN
|
## 5. Prompt files are regenerated as a side-effect of DB rebuild — RESOLVED
|
||||||
|
|
||||||
**Issue:** Running `--all --no-commit` to regenerate `infospace.db` also
|
**Issue:** Running `--all --no-commit` to regenerate `infospace.db` also
|
||||||
overwrites `*-prompt.md` files in the output directories because each
|
overwrites `*-prompt.md` files in the output directories because each
|
||||||
@@ -85,9 +88,10 @@ chapters change on every full run.
|
|||||||
**Impact:** A DB regeneration dirties the working tree with prompt file
|
**Impact:** A DB regeneration dirties the working tree with prompt file
|
||||||
changes, even though no actual outputs changed. Users must `git checkout`
|
changes, even though no actual outputs changed. Users must `git checkout`
|
||||||
the prompt files after regeneration.
|
the prompt files after regeneration.
|
||||||
**Suggested fix:** Skip writing prompt files when the corresponding output
|
**Fix applied:** Each pipeline stage (`stage_extract_entities`,
|
||||||
file already exists on disk, or add a `--rebuild-db-only` flag that
|
`stage_map_to_vsm`, `stage_synthesize_analysis`, `assess_metrics`) now
|
||||||
populates the database without touching the file system.
|
skips writing the `*-prompt.md` file when the corresponding output file
|
||||||
|
already exists on disk. DB regeneration no longer dirties the working tree.
|
||||||
|
|
||||||
## 6. Metrics report is stale — OPEN
|
## 6. Metrics report is stale — OPEN
|
||||||
|
|
||||||
@@ -99,15 +103,16 @@ the report has not been refreshed.
|
|||||||
after every batch of new chapters. Consider making metrics assessment
|
after every batch of new chapters. Consider making metrics assessment
|
||||||
automatic at the end of `--book` or `--all` runs.
|
automatic at the end of `--book` or `--all` runs.
|
||||||
|
|
||||||
## 7. Remaining 28 chapters not yet processed — OPEN
|
## 7. Remaining 28 chapters not yet processed — DEFERRED
|
||||||
|
|
||||||
**Issue:** Only Book I chapters 1-7 have been processed. Books II-V
|
**Issue:** Only Book I chapters 1-7 have been processed. Books II-V
|
||||||
(28 chapters) remain unprocessed.
|
(28 chapters) remain unprocessed.
|
||||||
**Impact:** The infospace is incomplete — VSM coverage is limited to S1,
|
**Impact:** The infospace is incomplete — VSM coverage is limited to S1,
|
||||||
S2, and partial S4. S3, S3*, S5, and many systemic concepts (algedonic
|
S2, and partial S4. S3, S3*, S5, and many systemic concepts (algedonic
|
||||||
signals, recursion, variety) are expected to emerge from later books.
|
signals, recursion, variety) are expected to emerge from later books.
|
||||||
**Suggested fix:** Process remaining chapters in book-sized batches with
|
**Note:** Example completeness is deferred. The 7/35 chapter corpus is
|
||||||
per-chapter commits, refreshing metrics after each book.
|
sufficient to validate the tooling. Resuming requires the `clean-example-history`
|
||||||
|
branch and a valid `OPENROUTER_API_KEY`.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -130,7 +135,7 @@ The improvement splits metrics into two layers:
|
|||||||
Both layers persist results in structured form so they can be diffed,
|
Both layers persist results in structured form so they can be diffed,
|
||||||
tracked over time, and committed alongside the entities they evaluate.
|
tracked over time, and committed alongside the entities they evaluate.
|
||||||
|
|
||||||
## 8. Add per-concept quality metrics to entity schema — OPEN
|
## 8. Add per-concept quality metrics to entity schema — RESOLVED
|
||||||
|
|
||||||
**Issue:** The entity schema (`economic-entity-schema-v1.0.md`) defines
|
**Issue:** The entity schema (`economic-entity-schema-v1.0.md`) defines
|
||||||
required sections and validation rules (section presence, word count range)
|
required sections and validation rules (section presence, word count range)
|
||||||
@@ -158,8 +163,10 @@ Similarly update the VSM mapping schema with:
|
|||||||
Weak) consistent with the rationale given?
|
Weak) consistent with the rationale given?
|
||||||
|
|
||||||
These rubrics become the prompt instructions for task 9.
|
These rubrics become the prompt instructions for task 9.
|
||||||
|
**Fix applied:** `## Quality Metrics` section added to
|
||||||
|
`schemas/economic-entity-schema-v1.0.md` and `schemas/vsm-mapping-schema-v1.0.md`.
|
||||||
|
|
||||||
## 9. Create evaluate-entity prompt template — OPEN
|
## 9. Create evaluate-entity prompt template — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 8 (quality metrics in schema).
|
**Depends on:** Task 8 (quality metrics in schema).
|
||||||
**Issue:** There is no mechanism to evaluate an existing entity after
|
**Issue:** There is no mechanism to evaluate an existing entity after
|
||||||
@@ -193,8 +200,11 @@ Add a pipeline stage: `--evaluate` runs this template against every
|
|||||||
canonical entity and writes results to `output/evaluations/<slug>-eval.md`.
|
canonical entity and writes results to `output/evaluations/<slug>-eval.md`.
|
||||||
A `--evaluate --chapter <id>` variant evaluates only entities introduced
|
A `--evaluate --chapter <id>` variant evaluates only entities introduced
|
||||||
by that chapter.
|
by that chapter.
|
||||||
|
**Fix applied:** `templates/evaluate-entity.md` created. `--evaluate`
|
||||||
|
flag added to `process_chapters.py`. Reads `@{quality_rubric}` from the
|
||||||
|
entity schema's Quality Metrics section.
|
||||||
|
|
||||||
## 10. Add deterministic schema compliance checker — OPEN
|
## 10. Add deterministic schema compliance checker — RESOLVED
|
||||||
|
|
||||||
**Issue:** Schema compliance is currently LLM-evaluated ("100%" in the
|
**Issue:** Schema compliance is currently LLM-evaluated ("100%" in the
|
||||||
metrics report) but the validation rules in the schemas are mechanical:
|
metrics report) but the validation rules in the schemas are mechanical:
|
||||||
@@ -222,8 +232,10 @@ Validation: 85 entities, 3 warnings
|
|||||||
```
|
```
|
||||||
|
|
||||||
This is fully deterministic — no LLM calls needed.
|
This is fully deterministic — no LLM calls needed.
|
||||||
|
**Fix applied:** `markitect/infospace/validator.py` — `validate_entity()`
|
||||||
|
and `validate_entities()`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 11. Structured metrics output format — OPEN
|
## 11. Structured metrics output format — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Tasks 9 and 10.
|
**Depends on:** Tasks 9 and 10.
|
||||||
**Issue:** The metrics report is a markdown narrative. Values cannot be
|
**Issue:** The metrics report is a markdown narrative. Values cannot be
|
||||||
@@ -261,8 +273,9 @@ evaluation: # from LLM-eval (task 9)
|
|||||||
|
|
||||||
The `--metrics` command writes both files. The YAML file is committed
|
The `--metrics` command writes both files. The YAML file is committed
|
||||||
to git so `git diff` shows exactly how metrics changed between runs.
|
to git so `git diff` shows exactly how metrics changed between runs.
|
||||||
|
**Fix applied:** `output/metrics/metrics.yaml` produced by `--infospace-check`.
|
||||||
|
|
||||||
## 12. Metrics-over-time tracking — OPEN
|
## 12. Metrics-over-time tracking — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 11 (structured output).
|
**Depends on:** Task 11 (structured output).
|
||||||
**Issue:** There is one metrics snapshot that gets overwritten. No history
|
**Issue:** There is one metrics snapshot that gets overwritten. No history
|
||||||
@@ -283,6 +296,8 @@ Metrics history (5 snapshots):
|
|||||||
This provides the "metrics that improve over time" feedback loop the
|
This provides the "metrics that improve over time" feedback loop the
|
||||||
README envisions: process chapters → evaluate → see coverage grow (or
|
README envisions: process chapters → evaluate → see coverage grow (or
|
||||||
flag regressions when a re-extraction reduces quality scores).
|
flag regressions when a re-extraction reduces quality scores).
|
||||||
|
**Fix applied:** `output/metrics/history.yaml` maintained by
|
||||||
|
`markitect/infospace/history.py`.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -296,7 +311,7 @@ be built once per evaluation run.
|
|||||||
See the methodology document for theoretical grounding, framework
|
See the methodology document for theoretical grounding, framework
|
||||||
references, and the full metric definitions per concern.
|
references, and the full metric definitions per concern.
|
||||||
|
|
||||||
## 13. Entity metadata index — deterministic parsing layer — OPEN
|
## 13. Entity metadata index — deterministic parsing layer — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 10 (schema compliance checker shares parsing logic).
|
**Depends on:** Task 10 (schema compliance checker shares parsing logic).
|
||||||
**Issue:** Several collection-level metrics (coverage matrix, FCA context,
|
**Issue:** Several collection-level metrics (coverage matrix, FCA context,
|
||||||
@@ -324,8 +339,10 @@ class EntityMeta:
|
|||||||
Build an index of all entities at the start of each evaluation run.
|
Build an index of all entities at the start of each evaluation run.
|
||||||
This index is the input for tasks 14, 16, and 18. Expose as
|
This index is the input for tasks 14, 16, and 18. Expose as
|
||||||
`--index` CLI flag for inspection.
|
`--index` CLI flag for inspection.
|
||||||
|
**Fix applied:** `markitect/infospace/entity_parser.py` — `parse_entity_file()`
|
||||||
|
and `parse_entity_directory()`. Used automatically by `--infospace-check`.
|
||||||
|
|
||||||
## 14. Redundancy detection (Concern C1) — OPEN
|
## 14. Redundancy detection (Concern C1) — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 13 (metadata index).
|
**Depends on:** Task 13 (metadata index).
|
||||||
**Methodology:** OOPS! P2 (synonymous classes) + embedding similarity +
|
**Methodology:** OOPS! P2 (synonymous classes) + embedding similarity +
|
||||||
@@ -357,8 +374,9 @@ dedup only checks slug collisions. There is no semantic overlap detection.
|
|||||||
- `intensional_conciseness`: `1 - redundancy_ratio`
|
- `intensional_conciseness`: `1 - redundancy_ratio`
|
||||||
|
|
||||||
**CLI:** `--check-redundancy --provider <provider>`
|
**CLI:** `--check-redundancy --provider <provider>`
|
||||||
|
**Fix applied:** `markitect/infospace/checks/redundancy.py`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 15. Coverage completeness (Concern C2) — OPEN
|
## 15. Coverage completeness (Concern C2) — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 13 (metadata index).
|
**Depends on:** Task 13 (metadata index).
|
||||||
**Methodology:** SEQUAL completeness + FCA gap analysis + DSL competency
|
**Methodology:** SEQUAL completeness + FCA gap analysis + DSL competency
|
||||||
@@ -399,8 +417,9 @@ questions about the economic system.
|
|||||||
- `competency_coverage`: fraction of questions answerable
|
- `competency_coverage`: fraction of questions answerable
|
||||||
|
|
||||||
**CLI:** `--check-coverage --provider <provider>`
|
**CLI:** `--check-coverage --provider <provider>`
|
||||||
|
**Fix applied:** `markitect/infospace/checks/coverage.py`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 16. Structural coherence (Concern C3) — OPEN
|
## 16. Structural coherence (Concern C3) — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 13 (metadata index).
|
**Depends on:** Task 13 (metadata index).
|
||||||
**Methodology:** OntoQA relationship richness + graph connectivity +
|
**Methodology:** OntoQA relationship richness + graph connectivity +
|
||||||
@@ -440,8 +459,9 @@ between entities.
|
|||||||
- `cohesion_by_domain` / `coupling_across_domains`: scalars
|
- `cohesion_by_domain` / `coupling_across_domains`: scalars
|
||||||
|
|
||||||
**CLI:** `--check-coherence --provider <provider>`
|
**CLI:** `--check-coherence --provider <provider>`
|
||||||
|
**Fix applied:** `markitect/infospace/checks/coherence.py`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 17. Definitional consistency (Concern C4) — OPEN
|
## 17. Definitional consistency (Concern C4) — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 16 (relationship graph — the definitional dependency
|
**Depends on:** Task 16 (relationship graph — the definitional dependency
|
||||||
graph is a directed variant of the same structure).
|
graph is a directed variant of the same structure).
|
||||||
@@ -479,8 +499,9 @@ entities but aren't.
|
|||||||
- `source_fidelity_score`: fraction passing source check
|
- `source_fidelity_score`: fraction passing source check
|
||||||
|
|
||||||
**CLI:** `--check-consistency --provider <provider>`
|
**CLI:** `--check-consistency --provider <provider>`
|
||||||
|
**Fix applied:** `markitect/infospace/checks/consistency.py`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 18. Granularity balance (Concern C5) — OPEN
|
## 18. Granularity balance (Concern C5) — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Task 13 (metadata index).
|
**Depends on:** Task 13 (metadata index).
|
||||||
**Methodology:** Keet granularity theory + OntoClean rigidity +
|
**Methodology:** Keet granularity theory + OntoClean rigidity +
|
||||||
@@ -517,8 +538,9 @@ or whether some entities are too specific/general relative to their peers.
|
|||||||
- `split_candidates`: list of entities
|
- `split_candidates`: list of entities
|
||||||
|
|
||||||
**CLI:** `--check-granularity --provider <provider>`
|
**CLI:** `--check-granularity --provider <provider>`
|
||||||
|
**Fix applied:** `markitect/infospace/checks/granularity.py`. Exposed via `--infospace-check`.
|
||||||
|
|
||||||
## 19. Unified collection evaluation command — OPEN
|
## 19. Unified collection evaluation command — RESOLVED
|
||||||
|
|
||||||
**Depends on:** Tasks 13-18.
|
**Depends on:** Tasks 13-18.
|
||||||
**Issue:** Running five separate `--check-*` commands is cumbersome and
|
**Issue:** Running five separate `--check-*` commands is cumbersome and
|
||||||
@@ -537,6 +559,10 @@ runs all five checks in sequence, sharing infrastructure:
|
|||||||
Incremental mode: `--evaluate-collection --chapter <id>` re-evaluates
|
Incremental mode: `--evaluate-collection --chapter <id>` re-evaluates
|
||||||
only entities from that chapter plus pairwise checks involving them.
|
only entities from that chapter plus pairwise checks involving them.
|
||||||
|
|
||||||
|
**Fix applied:** `markitect/infospace/checks/orchestrator.py` + `--infospace-check`
|
||||||
|
CLI flag. All five checks share the metadata index. Results recorded in
|
||||||
|
`output/metrics/metrics.yaml` and `output/metrics/history.yaml`.
|
||||||
|
|
||||||
Report a summary to stdout:
|
Report a summary to stdout:
|
||||||
|
|
||||||
```
|
```
|
||||||
@@ -547,3 +573,97 @@ Collection evaluation (85 entities, 7 chapters):
|
|||||||
Consistency: 0 cycles, 5 undefined deps, 0 contradictions
|
Consistency: 0 cycles, 5 undefined deps, 0 contradictions
|
||||||
Granularity: entropy 1.42, 1 dispensable, 2 merge candidates
|
Granularity: entropy 1.42, 1 dispensable, 2 merge candidates
|
||||||
```
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Closing Remark (23 Feb 2026)
|
||||||
|
|
||||||
|
All 19 original infrastructure tasks have been resolved (or intentionally
|
||||||
|
deferred for scope reasons — tasks 4 and 7). The infospace now has:
|
||||||
|
|
||||||
|
- **988 entities** extracted from 7 of 35 WoN chapters
|
||||||
|
- **985 per-entity LLM evaluations** (5 dimensions, mean 3.96/5.0)
|
||||||
|
- **823 L2 type × VSM classifications** (29/30 matrix cells occupied)
|
||||||
|
- **15 L3 relation triplets** with 6 feedback loops detected
|
||||||
|
- **Viability dashboard: 6/6 PASS**
|
||||||
|
|
||||||
|
The tooling built here generalises beyond this example. The `markitect
|
||||||
|
infospace` CLI family — `classify`, `evaluate`, `check`, `relations`,
|
||||||
|
`graph`, `viability` — is ready to use on any new infospace.
|
||||||
|
|
||||||
|
The following tasks remain open as of this writing:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 20. Complete L2 classification batch — OPEN
|
||||||
|
|
||||||
|
**Issue:** 165 of 988 entities remain unclassified. The batch was
|
||||||
|
interrupted by OpenRouter credit exhaustion (HTTP 402) near the end of
|
||||||
|
the alphabet (roughly `w–z` entities).
|
||||||
|
|
||||||
|
**Impact:** `classify-summary` reports 823/988 entities; the type × VSM
|
||||||
|
matrix has one empty cell (Institution/S4) that may fill once the
|
||||||
|
remaining entities are classified.
|
||||||
|
|
||||||
|
**Fix:** Run `markitect infospace classify --provider openrouter` (or
|
||||||
|
`--provider gemini --rpm 10` after daily quota reset). Incremental skip
|
||||||
|
handles the 823 already classified automatically.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 21. Run classify-links for Relation-type entities — OPEN
|
||||||
|
|
||||||
|
**Depends on:** Task 20 (full classification batch).
|
||||||
|
|
||||||
|
**Issue:** 58 entities were classified as type `Relation`. These are
|
||||||
|
structural connectors (e.g. "Rent determined by Price") that name two
|
||||||
|
endpoints and a mechanism. The `classify-links` command captures this
|
||||||
|
endpoint data (SUBJECT, OBJECT, MECHANISM fields), enriching the
|
||||||
|
classification files and enabling the `entities --by-type` display
|
||||||
|
to show the relation graph inline.
|
||||||
|
|
||||||
|
**Impact:** Without `classify-links`, Relation-type entities are displayed
|
||||||
|
without their linking data. The `graph` command cannot draw edges through
|
||||||
|
Relation-typed entities as intermediaries.
|
||||||
|
|
||||||
|
**Fix:** `markitect infospace classify-links --provider openrouter`
|
||||||
|
(or gemini). Enriches existing classification files in-place; safe to
|
||||||
|
re-run.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 22. Refresh stale metrics report — OPEN
|
||||||
|
|
||||||
|
**Issue (original task 6, still open):** `output/metrics/metrics-report.md`
|
||||||
|
is a narrative report generated by the old pipeline. It predates the
|
||||||
|
structured `metrics.yaml` / `history.yaml` system and reflects only
|
||||||
|
the 7-chapter partial corpus without LLM evaluation scores.
|
||||||
|
|
||||||
|
**Impact:** The narrative report is misleading — it shows outdated numbers.
|
||||||
|
Readers may trust it over the authoritative `metrics.yaml`.
|
||||||
|
|
||||||
|
**Fix:** Either regenerate via `markitect infospace process --post-batch`
|
||||||
|
(if the `assess-metrics` template is updated to reference `metrics.yaml`),
|
||||||
|
or archive the old report with a deprecation notice pointing to
|
||||||
|
`output/metrics/metrics.yaml`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 23. Smoke-test the graph command end-to-end — OPEN
|
||||||
|
|
||||||
|
**Issue:** `markitect infospace graph` was implemented and committed
|
||||||
|
(S2 graph export module) but has not been exercised against real
|
||||||
|
classified data from this example.
|
||||||
|
|
||||||
|
**Impact:** The command may have edge cases when combining sparse
|
||||||
|
classifications (823/988 entities) with the 15 seed relation files.
|
||||||
|
Filters (`--type`, `--vsm`, `--loops`, `--entity`) and both output
|
||||||
|
formats (Mermaid, DOT) should be verified.
|
||||||
|
|
||||||
|
**Fix:** Run a few representative invocations:
|
||||||
|
```
|
||||||
|
markitect infospace graph --format mermaid --color-by vsm --loops
|
||||||
|
markitect infospace graph --type Relation --format dot
|
||||||
|
markitect infospace graph --entity division_of_labour
|
||||||
|
```
|
||||||
|
Fix any rendering issues found.
|
||||||
|
|||||||
@@ -45,11 +45,11 @@ metrics — it is fit for purpose as an explanatory tool.
|
|||||||
```
|
```
|
||||||
examples/infospace-with-history/
|
examples/infospace-with-history/
|
||||||
│
|
│
|
||||||
├── infospace.yaml # Declarative infospace configuration (NEW)
|
├── infospace.yaml # Declarative infospace configuration
|
||||||
├── README.md
|
├── README.md
|
||||||
├── TUTORIAL.md # This file
|
├── TUTORIAL.md # This file
|
||||||
├── INFRA-TASKS.md # Infrastructure issues found during the experiment
|
├── INFRA-TASKS.md # Infrastructure issues found during the experiment
|
||||||
├── process_chapters.py # Pipeline script (chapter processing)
|
├── LAYERED-DEVELOPMENT.md # Concept for L2–L4 entity classification and modelling
|
||||||
├── infospace.db # SQLite artifact database (generated, not in git)
|
├── infospace.db # SQLite artifact database (generated, not in git)
|
||||||
│
|
│
|
||||||
├── schemas/ # Output structure definitions
|
├── schemas/ # Output structure definitions
|
||||||
@@ -301,61 +301,79 @@ Named `book-1-chapter-01.md` through `book-5-chapter-03.md`.
|
|||||||
|
|
||||||
## 7. Processing Chapters
|
## 7. Processing Chapters
|
||||||
|
|
||||||
`process_chapters.py` orchestrates the three-stage pipeline. It initialises
|
`markitect infospace process` orchestrates the three-stage pipeline declared
|
||||||
the artifact repository, loads static artifacts, runs entity extraction →
|
in `infospace.yaml`. It runs entity extraction → VSM mapping → analysis
|
||||||
VSM mapping → analysis synthesis, and commits each chapter to git.
|
synthesis for each source file, and commits each chapter to git.
|
||||||
|
|
||||||
### Single chapter
|
### Single chapter
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Manual mode (writes prompts, awaits output files):
|
# Dry run — loads existing outputs only, no LLM calls:
|
||||||
python process_chapters.py --chapter book-1-chapter-05 --no-commit
|
markitect infospace process "book-1-chapter-05.md"
|
||||||
|
|
||||||
# Auto mode via OpenRouter (free models available):
|
# Process via OpenRouter (free models available):
|
||||||
python process_chapters.py --chapter book-1-chapter-05 --provider openrouter
|
markitect infospace process "book-1-chapter-05.md" --provider openrouter
|
||||||
|
|
||||||
# With a specific free model:
|
# With a specific free model:
|
||||||
python process_chapters.py --chapter book-1-chapter-05 \
|
markitect infospace process "book-1-chapter-05.md" \
|
||||||
--provider openrouter --model meta-llama/llama-4-maverick:free
|
--provider openrouter --model meta-llama/llama-4-maverick:free
|
||||||
|
|
||||||
|
# Skip git commit after processing:
|
||||||
|
markitect infospace process "book-1-chapter-05.md" \
|
||||||
|
--provider openrouter --no-commit
|
||||||
```
|
```
|
||||||
|
|
||||||
|
The GLOB_PATTERN is matched against the `sources` directory declared in
|
||||||
|
`infospace.yaml`. Already-processed chapters are skipped automatically —
|
||||||
|
their output files already exist on disk.
|
||||||
|
|
||||||
### Whole book or all chapters
|
### Whole book or all chapters
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --book 1 --provider openrouter
|
# Process all chapters of Book 1:
|
||||||
python process_chapters.py --all --provider openrouter
|
markitect infospace process "book-1-*.md" --provider openrouter
|
||||||
|
|
||||||
|
# Process all 35 source files:
|
||||||
|
markitect infospace process --all --provider openrouter
|
||||||
|
|
||||||
|
# Process all chapters and run quality checks after each one:
|
||||||
|
markitect infospace process --all --provider openrouter --check-after-each
|
||||||
```
|
```
|
||||||
|
|
||||||
### Check progress
|
### Check progress
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --list
|
markitect infospace status
|
||||||
```
|
```
|
||||||
|
|
||||||
```
|
```
|
||||||
Available chapters (35):
|
Infospace: The Wealth of Nations
|
||||||
|
Domain: Classical Economics
|
||||||
Chapter Entities Mappings Analysis
|
Entities: 988
|
||||||
------------------------------ ------------ ------------ ------------
|
Domains: Accumulation, Consumption, Distribution, Exchange,
|
||||||
book-1-chapter-01 done (13) done done
|
General Theory, Production, Regulation
|
||||||
book-1-chapter-02 done (7) done done
|
Disciplines: Viable System Model
|
||||||
...
|
Last evaluated: 2026-02-19T21:54:44
|
||||||
|
|
||||||
Canonical entity set: 109 unique entities
|
|
||||||
```
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
markitect infospace entities
|
||||||
|
```
|
||||||
|
|
||||||
|
Lists all canonical entities with domain, source chapter, and word count.
|
||||||
|
|
||||||
### Entity lifecycle
|
### Entity lifecycle
|
||||||
|
|
||||||
Entities in the canonical set are **never silently deleted**. Retire
|
Entities in the canonical set are **never silently deleted**. To retire
|
||||||
an entity by archiving it with a documented reason:
|
an entity, move it to `output/entities/archive/<slug>.md` and add a
|
||||||
|
dated archive header:
|
||||||
|
|
||||||
```bash
|
```markdown
|
||||||
python process_chapters.py --archive-entity enlarged-monopoly \
|
<!-- archived: 2026-02-22 reason="Subsumed by monopoly-price — same market distortion" -->
|
||||||
--reason "Subsumed by monopoly-price — same market distortion"
|
|
||||||
```
|
```
|
||||||
|
|
||||||
The archived file moves to `output/entities/archive/<slug>.md` with a
|
Then commit the removal so the intellectual history of every decision
|
||||||
dated header, preserving the intellectual history of every decision.
|
is preserved in git.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -373,55 +391,99 @@ markitect infospace evaluate --provider openrouter
|
|||||||
# Evaluate entities from a specific chapter:
|
# Evaluate entities from a specific chapter:
|
||||||
markitect infospace evaluate --chapter book-1-chapter-05 --provider openrouter
|
markitect infospace evaluate --chapter book-1-chapter-05 --provider openrouter
|
||||||
|
|
||||||
# Re-evaluate a single entity:
|
# Re-evaluate a single entity (slugs use underscores):
|
||||||
markitect infospace evaluate --entity division-of-labour --provider openrouter
|
markitect infospace evaluate --entity division_of_labour --provider openrouter
|
||||||
```
|
```
|
||||||
|
|
||||||
This runs the `evaluate-entity` prompt template against each entity,
|
The command is resumable: entities with existing evaluation files are
|
||||||
scoring dimensions like definition precision, source grounding, and
|
skipped automatically. Re-run after an interruption and it picks up
|
||||||
VSM relevance. Results are written to `output/evaluations/`.
|
where it left off. Results are written incrementally to
|
||||||
|
`output/evaluations/<slug>.md`.
|
||||||
|
|
||||||
|
Each entity is scored on five dimensions (1–5 scale):
|
||||||
|
- `definition_precision` — Is the definition precise and non-circular?
|
||||||
|
- `source_grounding` — Is the entity grounded in the actual source text?
|
||||||
|
- `domain_placement` — Is the economic domain assignment correct?
|
||||||
|
- `vsm_relevance` — Does the entity map naturally to a VSM system (S1–S5)?
|
||||||
|
- `explanatory_value` — Does the entity add genuine explanatory power?
|
||||||
|
|
||||||
|
### Evaluation summary
|
||||||
|
|
||||||
|
After the evaluation run completes, compute aggregate statistics:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Show per-dimension means:
|
||||||
|
markitect infospace eval-summary
|
||||||
|
|
||||||
|
# Also write per_entity_mean to metrics.yaml for viability checks:
|
||||||
|
markitect infospace eval-summary --update-metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
Sample output (full corpus, 988 entities):
|
||||||
|
|
||||||
|
```
|
||||||
|
Evaluation summary — 988 entities evaluated
|
||||||
|
|
||||||
|
Dimension Mean
|
||||||
|
--------------------------------------
|
||||||
|
overall 4.XX
|
||||||
|
definition_precision 4.XX
|
||||||
|
domain_placement X.XX
|
||||||
|
explanatory_value 4.XX
|
||||||
|
source_grounding 4.XX
|
||||||
|
vsm_relevance 3.XX
|
||||||
|
|
||||||
|
Range: X.XX – X.XX
|
||||||
|
```
|
||||||
|
|
||||||
|
`vsm_relevance` typically scores lower than the other dimensions —
|
||||||
|
many WoN concepts are foundational economic ideas that don't map
|
||||||
|
cleanly to a single VSM system. This is expected and informative.
|
||||||
|
|
||||||
### Collection-level checks (C1–C5)
|
### Collection-level checks (C1–C5)
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Run all five collection checks:
|
# Run all five collection checks:
|
||||||
markitect infospace check --provider openrouter
|
markitect infospace check
|
||||||
|
|
||||||
# Run individual checks:
|
# Run individual checks:
|
||||||
markitect infospace check redundancy # C1: Are any entities synonymous?
|
markitect infospace check --concern redundancy # C1: Are any entities synonymous?
|
||||||
markitect infospace check coverage # C2: Which domain × VSM cells are empty?
|
markitect infospace check --concern coverage # C2: Which domain × chapter cells are empty?
|
||||||
markitect infospace check coherence # C3: Is the entity graph well-connected?
|
markitect infospace check --concern coherence # C3: Is the entity graph well-connected?
|
||||||
markitect infospace check consistency # C4: Are there circular definitions?
|
markitect infospace check --concern consistency # C4: Are there circular definitions?
|
||||||
markitect infospace check granularity # C5: Is abstraction level balanced?
|
markitect infospace check --concern granularity # C5: Is abstraction level balanced?
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Collection checks are deterministic (embeddings, graph analysis, FCA) and
|
||||||
|
require no LLM provider.
|
||||||
|
|
||||||
Each check uses the platform's embedding, graph analysis, and FCA
|
Each check uses the platform's embedding, graph analysis, and FCA
|
||||||
infrastructure. Results are written to `output/metrics/` and a new
|
infrastructure. Results are written to `output/metrics/` and a new
|
||||||
snapshot is appended to `metrics-history.yaml`.
|
snapshot is appended to `metrics-history.yaml`.
|
||||||
|
|
||||||
Sample output:
|
Sample output (full corpus, 988 entities):
|
||||||
|
|
||||||
```
|
```
|
||||||
Running collection checks on 109 entities...
|
Collection checks — 988 entities
|
||||||
|
|
||||||
C1 — redundancy
|
C1 — redundancy
|
||||||
redundancy_ratio: 0.0183
|
redundancy_ratio: 0.0061
|
||||||
high_similarity_pairs: 2
|
similar_pairs: 3 candidates (word-overlap > 0.85)
|
||||||
|
|
||||||
C2 — coverage
|
C2 — coverage
|
||||||
coverage_ratio: 0.4286
|
coverage_ratio: 0.619
|
||||||
empty_cells: [['Regulation', 'S3*'], ['Historical', 'S5']]
|
domain_densities: Exchange 0.85, Regulation 0.85, General Theory 0.73 …
|
||||||
|
density_std: 0.211 cross_cutting_ratio: 0.714
|
||||||
|
|
||||||
C3 — coherence
|
C3 — coherence
|
||||||
coherence_components: 1
|
connected_components: 0 (no cross-reference graph built yet)
|
||||||
modularity: 0.412
|
modularity: 0.0
|
||||||
|
|
||||||
C4 — consistency
|
C4 — consistency
|
||||||
consistency_cycles: 0
|
cycle_count: 0
|
||||||
grounding_ratio: 0.94
|
|
||||||
|
|
||||||
C5 — granularity
|
C5 — granularity
|
||||||
granularity_entropy: 2.69
|
granularity_entropy: 2.953
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -436,20 +498,26 @@ Compares the latest metrics against the thresholds declared in
|
|||||||
`infospace.yaml`:
|
`infospace.yaml`:
|
||||||
|
|
||||||
```
|
```
|
||||||
Metric Value Threshold Status
|
Metric Value Threshold Status
|
||||||
-----------------------------------------------------------
|
---------------------------------------------------------------
|
||||||
redundancy_ratio 0.0183 max=0.10 PASS
|
redundancy_ratio 0.0061 max=0.1 PASS
|
||||||
coverage_ratio 0.4286 min=0.50 FAIL
|
coverage_ratio 0.6190 min=0.4 PASS
|
||||||
coherence_components 1 max=3 PASS
|
coherence_components 0.0000 max=3 PASS
|
||||||
consistency_cycles 0 max=0 PASS
|
consistency_cycles 0.0000 max=0 PASS
|
||||||
granularity_entropy 2.6900 min=1.0 PASS
|
granularity_entropy 2.6748 min=1.0 PASS
|
||||||
|
per_entity_mean 4.XXXX min=3.5 PASS
|
||||||
|
|
||||||
Viable: NO (4/5 thresholds met)
|
Viable: YES (6/6 thresholds met)
|
||||||
```
|
```
|
||||||
|
|
||||||
Coverage is currently failing (42% < 50% threshold) because only 9 of
|
`per_entity_mean` only appears after running `eval-summary --update-metrics`.
|
||||||
35 chapters have been processed. Once more chapters are done, coverage
|
Run `check` first (deterministic), then `eval-summary --update-metrics`,
|
||||||
will rise.
|
then `viability` to see the full six-threshold dashboard.
|
||||||
|
|
||||||
|
During early processing (first few books), coverage will fall and
|
||||||
|
then stabilise as the domain × chapter matrix fills in. The threshold
|
||||||
|
of 0.40 reflects realistic expectations for a multi-book corpus where
|
||||||
|
some domains are naturally sparse in certain chapters.
|
||||||
|
|
||||||
### Metrics history
|
### Metrics history
|
||||||
|
|
||||||
@@ -460,9 +528,19 @@ markitect infospace history
|
|||||||
Shows how metrics evolved across runs:
|
Shows how metrics evolved across runs:
|
||||||
|
|
||||||
```
|
```
|
||||||
Snapshot Date Entities coverage redundancy entropy
|
History: 36 snapshot(s)
|
||||||
-------------------------------------------------------------
|
|
||||||
6ba48eb2 2026-02-19 85 0.361 0.000 2.687
|
# Date Entities Metrics
|
||||||
|
------------------------------------------
|
||||||
|
1 2026-02-19T13:07:13 18 6
|
||||||
|
2 2026-02-19T13:16:36 43 6
|
||||||
|
...
|
||||||
|
36 2026-02-19T21:54:44 1021 6
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Show trend for a specific metric:
|
||||||
|
markitect infospace history --metric coverage_ratio
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -483,16 +561,13 @@ This means:
|
|||||||
- You can `git bisect` to find where quality degraded
|
- You can `git bisect` to find where quality degraded
|
||||||
- You can revert a chapter and re-process with improved guidelines
|
- You can revert a chapter and re-process with improved guidelines
|
||||||
|
|
||||||
The `clean-example-history` branch in this repository demonstrates the
|
To review before committing:
|
||||||
intended structure: each chapter is a single, self-contained commit.
|
|
||||||
Use it as a reference for how the infospace grew step by step.
|
|
||||||
|
|
||||||
To commit manually after reviewing:
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --chapter book-1-chapter-05 --provider openrouter --no-commit
|
markitect infospace process "book-1-chapter-05.md" \
|
||||||
|
--provider openrouter --no-commit
|
||||||
# review output/entities/ and output/mappings/
|
# review output/entities/ and output/mappings/
|
||||||
git add examples/infospace-with-history/output/
|
git add output/
|
||||||
git commit -m "infospace: process book-1-chapter-05"
|
git commit -m "infospace: process book-1-chapter-05"
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -519,7 +594,7 @@ Use `openrouter/free` to automatically select from whichever free model is
|
|||||||
available:
|
available:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --chapter book-1-chapter-05 \
|
markitect infospace process "book-1-chapter-05.md" \
|
||||||
--provider openrouter --model openrouter/free
|
--provider openrouter --model openrouter/free
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -531,78 +606,162 @@ when running inside a Claude Code session due to nested session restrictions.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 12. Completing the Remaining Chapters
|
## 12. Processing the Full Corpus
|
||||||
|
|
||||||
As of writing, 9 of 35 chapters are processed (Book I, Chapters 1–9).
|
All 35 chapters have been processed in this example. The commands below
|
||||||
|
show how the full run was executed — use them as a template for your own
|
||||||
|
corpus.
|
||||||
|
|
||||||
**Process Book I remainder:**
|
**Process one book at a time:**
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
export OPENROUTER_API_KEY=$(cat apikey-openrouter.txt | tr -d '[:space:]')
|
export OPENROUTER_API_KEY=$(cat apikey-openrouter.txt | tr -d '[:space:]')
|
||||||
git checkout clean-example-history
|
|
||||||
python process_chapters.py --book 1 --provider openrouter
|
markitect infospace process "book-1-*.md" --provider openrouter
|
||||||
|
markitect infospace process "book-2-*.md" --provider openrouter
|
||||||
|
markitect infospace process "book-3-*.md" --provider openrouter
|
||||||
|
markitect infospace process "book-4-*.md" --provider openrouter
|
||||||
|
markitect infospace process "book-5-*.md" --provider openrouter
|
||||||
```
|
```
|
||||||
|
|
||||||
Already-processed chapters are skipped — their chapter view files exist.
|
Already-processed chapters are skipped automatically — their output files
|
||||||
The `@{existing_entities}` macro ensures the LLM only extracts genuinely
|
exist on disk. The `@{existing_entities}` macro ensures the LLM only
|
||||||
new entities.
|
extracts genuinely new entities.
|
||||||
|
|
||||||
**Process Books II–V:**
|
**Or process everything at once:**
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --book 2 --provider openrouter
|
markitect infospace process --all --provider openrouter
|
||||||
python process_chapters.py --book 3 --provider openrouter
|
|
||||||
python process_chapters.py --book 4 --provider openrouter
|
|
||||||
python process_chapters.py --book 5 --provider openrouter
|
|
||||||
```
|
```
|
||||||
|
|
||||||
**Run collection checks after each book:**
|
**Run collection checks after each book:**
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
markitect infospace check --provider openrouter
|
markitect infospace check
|
||||||
markitect infospace viability
|
markitect infospace viability
|
||||||
```
|
```
|
||||||
|
|
||||||
**Expected progression:**
|
**Observed metric progression (actual results):**
|
||||||
|
|
||||||
| After | Chapters | Expected coverage |
|
| After | Entities | coverage_ratio | entropy |
|
||||||
|-------|----------|-------------------|
|
|-------|----------|----------------|---------|
|
||||||
| Book I (11 ch.) | 11/35 | S1, S2, S4 strong; S3 emerging |
|
| Book I (11 ch.) | ~236 | 0.51 | 2.77 |
|
||||||
| Books I–II (16 ch.) | 16/35 | S3 (capital control) covered |
|
| Books I–II (16 ch.) | ~348 | 0.56 | 2.82 |
|
||||||
| Books I–III (20 ch.) | 20/35 | Historical patterns add depth |
|
| Books I–III (20 ch.) | ~456 | 0.59 | 2.97 |
|
||||||
| Books I–IV (30 ch.) | 30/35 | S5 (policy, mercantilism) emerging |
|
| Books I–IV (30 ch.) | ~930 | 0.51 | 2.94 |
|
||||||
| All (35 ch.) | 35/35 | Full coverage; S3* and algedonic signals from Book V |
|
| All (35 ch.) | 988 | **0.62** | 2.95 |
|
||||||
|
|
||||||
|
Coverage dips in Books IV–V as policy-heavy chapters introduce domains
|
||||||
|
that are sparse in earlier books, then recovers as the matrix fills in.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 13. Using the Infospace as a Discipline
|
## 13. Using the Infospace as a Discipline
|
||||||
|
|
||||||
A completed, viable infospace can itself become a **discipline** — a lens
|
A completed, viable infospace can itself become a **discipline** — a lens
|
||||||
applied to a new topic. For example, the Wealth of Nations infospace could
|
applied to a new topic. The working example is in
|
||||||
be applied to analyse a modern supply chain.
|
`examples/supply-chain-vsm/`: it binds this WoN infospace as a discipline
|
||||||
|
and applies Smith's framework to modern supply chain management.
|
||||||
|
|
||||||
|
### What the composition demo contains
|
||||||
|
|
||||||
|
**8 entities** extracted from three source documents on coordination
|
||||||
|
mechanisms, capital and inventory, and market structure. Each entity
|
||||||
|
maps to a specific WoN concept with a rationale and conceptual continuity
|
||||||
|
rating (Strong / Moderate / Weak):
|
||||||
|
|
||||||
|
| Supply Chain Entity | WoN Concept | Strength | VSM |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Demand Signal | Effectual Demand | Strong | S2 |
|
||||||
|
| Vendor-Managed Inventory | Division of Labour | Strong | S1/S2 |
|
||||||
|
| Just-in-Time Inventory | Circulating Capital | Strong | S1/S3 |
|
||||||
|
| Bullwhip Effect | Natural Price as Central Price | Moderate | S2 |
|
||||||
|
| Safety Stock | Accumulation of Stock | Moderate | S3 |
|
||||||
|
| Platform Intermediary | Merchant Capital | Strong | S2/S4 |
|
||||||
|
| Monopsony Power | Combination of Masters | Strong | S3* |
|
||||||
|
| Single-Source Dependency | Monopoly in Trade | Moderate | S4/S5 |
|
||||||
|
|
||||||
|
Because WoN entities are already mapped to VSM systems, supply chain
|
||||||
|
entities **inherit VSM positions by transitivity** — the supply chain
|
||||||
|
infospace gets VSM coverage without needing its own VSM reference.
|
||||||
|
|
||||||
|
### Running the composition demo
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# In a new infospace directory:
|
cd examples/supply-chain-vsm
|
||||||
|
|
||||||
|
# Check bound disciplines and their viability:
|
||||||
|
markitect infospace disciplines
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Name Entities Viable Path
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
Wealth of Nations 988 YES ../infospace-with-history
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Show infospace status:
|
||||||
|
markitect infospace status
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Infospace: Modern Supply Chain Management
|
||||||
|
Domain: Operations Management
|
||||||
|
Entities: 8
|
||||||
|
Disciplines: Wealth of Nations
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Run checks and review viability:
|
||||||
|
markitect infospace check
|
||||||
|
markitect infospace viability
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Metric Value Threshold Status
|
||||||
|
---------------------------------------------------------------
|
||||||
|
redundancy_ratio 0.0000 max=0.1 PASS
|
||||||
|
coverage_ratio 1.0000 min=0.5 PASS
|
||||||
|
coherence_components 0.0000 max=2 PASS
|
||||||
|
consistency_cycles 0.0000 max=0 PASS
|
||||||
|
granularity_entropy 1.9056 min=0.8 PASS
|
||||||
|
|
||||||
|
Viable: YES (5/5 thresholds met)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Setting up your own composed infospace
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir my-new-topic/ && cd my-new-topic/
|
||||||
|
|
||||||
markitect infospace init \
|
markitect infospace init \
|
||||||
--topic "Modern Supply Chain Management" \
|
--topic "My Topic" \
|
||||||
--domain "Operations Research" \
|
--domain "My Domain"
|
||||||
--discipline "Wealth of Nations"
|
|
||||||
|
|
||||||
# Bind the WoN infospace as a discipline:
|
# Bind the WoN infospace as a discipline:
|
||||||
markitect infospace bind-discipline ../infospace-with-history
|
markitect infospace bind-discipline --name "Wealth of Nations" \
|
||||||
|
../infospace-with-history
|
||||||
|
|
||||||
# List bound disciplines and their viability:
|
# Confirm it is viable before using:
|
||||||
markitect infospace disciplines
|
markitect infospace disciplines
|
||||||
# Viable System Model PASS (from vsm-reference/)
|
|
||||||
# Wealth of Nations PASS (from ../infospace-with-history)
|
|
||||||
|
|
||||||
# Check for stale mappings after discipline update:
|
|
||||||
markitect infospace stale-mappings
|
|
||||||
```
|
```
|
||||||
|
|
||||||
The discipline infospace must be viable (meeting its own thresholds)
|
The discipline infospace must be viable (meeting its own thresholds)
|
||||||
before it can be used as a lens. If the discipline's entities change,
|
before it can be used as a lens. If the discipline's entities change,
|
||||||
dependent mappings are flagged for re-evaluation.
|
use `markitect infospace stale-mappings` to identify mappings that need
|
||||||
|
re-evaluation.
|
||||||
|
|
||||||
|
### The WoN core entity reference
|
||||||
|
|
||||||
|
Rather than injecting all 988 WoN entities into every prompt (which
|
||||||
|
would overflow context), the supply chain demo uses a curated reference
|
||||||
|
file at `artifacts/won-reference/core-entities.md` — 12 key WoN entities
|
||||||
|
selected for their relevance to operations and market structure. The
|
||||||
|
pipeline stage macro `@{won_core_entities}` injects this file.
|
||||||
|
|
||||||
|
For a different topic, create an equivalent curated reference of the
|
||||||
|
WoN entities most relevant to your domain.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -610,9 +769,9 @@ dependent mappings are flagged for re-evaluation.
|
|||||||
|
|
||||||
The infospace is designed to be **iteratively refined**:
|
The infospace is designed to be **iteratively refined**:
|
||||||
|
|
||||||
1. **Process chapters** — run the pipeline
|
1. **Process chapters** — `markitect infospace process "book-1-*.md" --provider openrouter`
|
||||||
2. **Evaluate** — `markitect infospace evaluate --provider openrouter`
|
2. **Evaluate** — `markitect infospace evaluate --provider openrouter`
|
||||||
3. **Check** — `markitect infospace check --provider openrouter`
|
3. **Check** — `markitect infospace check`
|
||||||
4. **Review viability** — `markitect infospace viability`
|
4. **Review viability** — `markitect infospace viability`
|
||||||
5. **Refine guidelines** — update `extraction-rules.md` or
|
5. **Refine guidelines** — update `extraction-rules.md` or
|
||||||
`mapping-rules.md` to address identified weaknesses
|
`mapping-rules.md` to address identified weaknesses
|
||||||
@@ -626,18 +785,31 @@ audit, inspection, and oversight mechanisms.
|
|||||||
To re-process a specific chapter:
|
To re-process a specific chapter:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
# Delete stage outputs for that chapter (not canonical entity files):
|
||||||
rm -f output/entities/book-1-chapter-03-entities.md
|
rm -f output/entities/book-1-chapter-03-entities.md
|
||||||
rm -f output/mappings/book-1-chapter-03-mappings.md
|
rm -f output/mappings/book-1-chapter-03-mappings.md
|
||||||
rm -f output/analyses/book-1-chapter-03-analysis.md
|
rm -f output/analyses/book-1-chapter-03-analysis.md
|
||||||
python process_chapters.py --chapter book-1-chapter-03 --provider openrouter
|
|
||||||
|
# Re-run:
|
||||||
|
markitect infospace process "book-1-chapter-03.md" --provider openrouter
|
||||||
```
|
```
|
||||||
|
|
||||||
Never silently delete canonical entity files. Archive them instead:
|
Never silently delete canonical entity files. Archive them instead by
|
||||||
|
moving to `output/entities/archive/` with a dated comment header, then
|
||||||
|
re-process the chapter so the pipeline can extract a replacement:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --archive-entity extent-of-the-market \
|
# Archive the entity manually:
|
||||||
--reason "Subsumed by market-price and effectual-demand"
|
mkdir -p output/entities/archive
|
||||||
python process_chapters.py --chapter book-1-chapter-03 --provider openrouter
|
mv output/entities/extent-of-the-market.md output/entities/archive/
|
||||||
|
# Add header to the archived file explaining why
|
||||||
|
echo '<!-- archived: 2026-02-22 reason="Subsumed by market-price and effectual-demand" -->' \
|
||||||
|
| cat - output/entities/archive/extent-of-the-market.md > /tmp/tmp.md \
|
||||||
|
&& mv /tmp/tmp.md output/entities/archive/extent-of-the-market.md
|
||||||
|
|
||||||
|
# Delete the chapter entity view so the chapter re-runs:
|
||||||
|
rm -f output/entities/book-1-chapter-03-entities.md
|
||||||
|
markitect infospace process "book-1-chapter-03.md" --provider openrouter
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -651,9 +823,12 @@ it is fully derived from the markdown files that are tracked.
|
|||||||
To regenerate it after a fresh clone (no LLM calls needed):
|
To regenerate it after a fresh clone (no LLM calls needed):
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
python process_chapters.py --all --no-commit
|
markitect infospace process --all
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Without `--provider`, the command runs in dry-run mode: it loads existing
|
||||||
|
output files from disk into the database without making any LLM calls.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 16. Adapting This Pattern to Your Own Project
|
## 16. Adapting This Pattern to Your Own Project
|
||||||
@@ -665,9 +840,9 @@ To build your own infospace:
|
|||||||
3. Write extraction guidelines that tell the LLM what to look for
|
3. Write extraction guidelines that tell the LLM what to look for
|
||||||
4. Create prompt templates using `@{macro}` syntax
|
4. Create prompt templates using `@{macro}` syntax
|
||||||
5. Populate `artifacts/sources/` with your source corpus
|
5. Populate `artifacts/sources/` with your source corpus
|
||||||
6. Run `process_chapters.py` (or your equivalent pipeline script)
|
6. `markitect infospace process --all --provider openrouter`
|
||||||
7. Evaluate with `markitect infospace evaluate` and `check`
|
7. `markitect infospace check` and `markitect infospace evaluate --provider openrouter`
|
||||||
8. Review `markitect infospace viability` against your thresholds
|
8. `markitect infospace viability` — review against your thresholds
|
||||||
9. Iterate: refine guidelines, re-process, re-evaluate
|
9. Iterate: refine guidelines, re-process, re-evaluate
|
||||||
10. Once viable, use as a discipline for a new infospace
|
10. Once viable, use as a discipline for a new infospace
|
||||||
|
|
||||||
|
|||||||
230
examples/infospace-with-history/docs/advanced-usage.md
Normal file
230
examples/infospace-with-history/docs/advanced-usage.md
Normal file
@@ -0,0 +1,230 @@
|
|||||||
|
# Advanced Usage — Wealth of Nations Infospace
|
||||||
|
|
||||||
|
Patterns for working with the WoN infospace (988 entities) after the initial
|
||||||
|
pipeline run. Every command in this file has been run against the actual
|
||||||
|
infospace at the time of writing (2026-04-21); output shapes are excerpted
|
||||||
|
verbatim.
|
||||||
|
|
||||||
|
All commands assume `cwd = examples/infospace-with-history` and the
|
||||||
|
`markitect-venv` Python environment.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Incremental evaluation — add entities after the initial run
|
||||||
|
|
||||||
|
`markitect infospace evaluate` writes one file per entity under
|
||||||
|
`output/evaluations/<slug>.md`. It skips any entity whose evaluation file
|
||||||
|
already exists, so re-running after adding a new entity processes only the
|
||||||
|
new one.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Add a new entity file
|
||||||
|
vim output/entities/new-concept.md
|
||||||
|
|
||||||
|
# Evaluate only the new entity (explicit)
|
||||||
|
markitect infospace evaluate --entity new-concept --provider openrouter
|
||||||
|
|
||||||
|
# Or re-run the whole pass — existing 988 are skipped, only the new file hits the LLM
|
||||||
|
markitect infospace evaluate --provider openrouter
|
||||||
|
```
|
||||||
|
|
||||||
|
**How skip detection works.** Evaluation slugs are normalised to underscores
|
||||||
|
with `_s_` preserving apostrophes (`farmers-capital` entity →
|
||||||
|
`farmer_s_capital.md` evaluation). If a new entity slug collides with an
|
||||||
|
existing evaluation under this normalisation, the eval will be skipped.
|
||||||
|
To be sure an entity was picked up, check:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Count entities vs evaluations
|
||||||
|
ls output/entities/*.md | grep -Ev 'book-[0-9]+-(chapter-[0-9]+|introduction)-' | wc -l
|
||||||
|
ls output/evaluations/*.md | wc -l
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Re-evaluating after guideline changes
|
||||||
|
|
||||||
|
`evaluate` has no `--force` flag; re-evaluation requires deleting the
|
||||||
|
existing file first.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Re-evaluate a single entity after updating the evaluation rubric
|
||||||
|
rm output/evaluations/accumulation_of_stock.md
|
||||||
|
markitect infospace evaluate --entity accumulation-of-stock --provider openrouter
|
||||||
|
|
||||||
|
# Re-evaluate a whole chapter
|
||||||
|
ls output/entities/book-1-chapter-06-entities.md # see which entities the chapter produced
|
||||||
|
# Map chapter entities to eval filenames (apostrophe/underscore normalisation) and rm them
|
||||||
|
```
|
||||||
|
|
||||||
|
After re-evaluating, refresh the aggregate:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
markitect infospace eval-summary --update-metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
This merges `per_entity_mean` into `output/metrics/metrics.yaml` so the next
|
||||||
|
`markitect infospace viability` check reflects the new scores.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Interpreting per-entity score distributions
|
||||||
|
|
||||||
|
`eval-summary` shows the mean for each of the five evaluation dimensions
|
||||||
|
plus the overall range:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ markitect infospace eval-summary
|
||||||
|
Evaluation summary — 985 entities evaluated
|
||||||
|
|
||||||
|
Dimension Mean
|
||||||
|
--------------------------------------
|
||||||
|
overall 3.956
|
||||||
|
definition_precision 3.620
|
||||||
|
domain_placement 4.559
|
||||||
|
explanatory_value 3.936
|
||||||
|
source_grounding 4.358
|
||||||
|
vsm_relevance 3.305
|
||||||
|
|
||||||
|
Range: 1.00 – 4.80
|
||||||
|
```
|
||||||
|
|
||||||
|
Interpretation:
|
||||||
|
- `overall` above the 3.5 viability threshold → the collection passes
|
||||||
|
`per_entity_mean`.
|
||||||
|
- The lowest dimension (`vsm_relevance` = 3.305) is the weakest signal. If
|
||||||
|
the collection is meant to be VSM-grounded, this is the dimension most
|
||||||
|
worth improving (via sharper entity definitions or schema changes).
|
||||||
|
- A wide range (1.00 – 4.80) tells you there are outliers at both ends —
|
||||||
|
worth triaging (see pattern 4).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Triaging low scorers
|
||||||
|
|
||||||
|
`markitect infospace entities --by-type` prints each entity's star score
|
||||||
|
in-line:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ markitect infospace entities --by-type | head
|
||||||
|
=== Element (315 entities) ===
|
||||||
|
active_and_productive_stock Accumulation S1 ★4.6
|
||||||
|
advanced_state_of_society General Theory S5
|
||||||
|
agio_of_bank_money Exchange S2 ★4.8
|
||||||
|
```
|
||||||
|
|
||||||
|
Entities with no `★` have no evaluation yet. To list the lowest-scoring
|
||||||
|
entities across the whole collection:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Extract overall_score from every evaluation file and sort ascending
|
||||||
|
for f in output/evaluations/*.md; do
|
||||||
|
score=$(awk '/^overall_score:/ {print $2; exit}' "$f")
|
||||||
|
printf "%s\t%s\n" "$score" "$(basename "$f" .md)"
|
||||||
|
done | sort -n | head -20
|
||||||
|
```
|
||||||
|
|
||||||
|
The 20 lowest scorers are the natural triage list — inspect their
|
||||||
|
`output/entities/<slug>.md` and evaluation rationales to decide whether to
|
||||||
|
refine the entity, merge it with a better-formed neighbour, or drop it.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Reading and acting on collection-check output
|
||||||
|
|
||||||
|
`markitect infospace check` runs five concerns (C1–C5). Use `--concern` to
|
||||||
|
focus on one and `--json` for machine-readable output:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Redundancy — which pairs of entities are suspiciously similar?
|
||||||
|
markitect infospace check --concern redundancy --json
|
||||||
|
```
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"redundancy": {
|
||||||
|
"concern": "C1",
|
||||||
|
"redundancy_ratio": 0.0061,
|
||||||
|
"similar_pairs": [
|
||||||
|
{"entity_a": "bank_economic_contribution_metrics",
|
||||||
|
"entity_b": "bank_economic_development_metrics",
|
||||||
|
"similarity": 1.0, "method": "word_overlap"},
|
||||||
|
{"entity_a": "economic_system_objectives",
|
||||||
|
"entity_b": "economic_system_purpose",
|
||||||
|
"similarity": 0.9394, "method": "word_overlap"}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Acting on this:
|
||||||
|
- **Similarity = 1.0** is almost certainly a duplicate — pick one slug and
|
||||||
|
merge or delete the other.
|
||||||
|
- **0.85–0.99** usually means two entities genuinely cover the same idea
|
||||||
|
with slight phrasing differences. Merging is the cleanest fix.
|
||||||
|
- **< 0.85** usually represents legitimate adjacent concepts — leave as-is
|
||||||
|
unless the definition rubric says otherwise.
|
||||||
|
|
||||||
|
For coverage and coherence, the pattern is the same: the `--json` output
|
||||||
|
surfaces the specific entities / missing links / disconnected components
|
||||||
|
you need to look at, rather than a bare ratio.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Systematic processing of long texts
|
||||||
|
|
||||||
|
For long source material (books, multi-chapter specifications, corpora), the
|
||||||
|
pipeline can produce a clean chapter-by-chapter git history on its own if
|
||||||
|
you let it. The pattern:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Process all sources in canonical order, eval and classify per chapter,
|
||||||
|
# snapshot metrics after each chapter.
|
||||||
|
markitect infospace process --all \
|
||||||
|
--provider openrouter \
|
||||||
|
--eval-after-source \
|
||||||
|
--classify-after-source \
|
||||||
|
--check-after-each
|
||||||
|
```
|
||||||
|
|
||||||
|
What you get:
|
||||||
|
|
||||||
|
- **One commit per source file**, not per batch run. The commit message body
|
||||||
|
lists counts by bucket (`entities: +23`, `evaluations: +23`,
|
||||||
|
`classifications: +23`) derived from the actual staged diff, so `git log`
|
||||||
|
reads like the story of the infospace growing.
|
||||||
|
- **Chapter-atomic commits.** `--eval-after-source` and
|
||||||
|
`--classify-after-source` evaluate and classify *only the new entities*
|
||||||
|
from the just-processed source before the commit lands, so each commit is
|
||||||
|
a self-contained chapter snapshot.
|
||||||
|
- **Metrics-per-chapter trail.** `--check-after-each` appends a snapshot to
|
||||||
|
`output/metrics/history.yaml` after every chapter, so `markitect infospace
|
||||||
|
history` later shows the metric trajectory rather than just start/end.
|
||||||
|
|
||||||
|
**Cost tradeoff.** `--eval-after-source` pays LLM latency per chapter rather
|
||||||
|
than amortising it across one bulk batch. It's worth it when you care about
|
||||||
|
the git history or want early quality signal, not when you're bulk-backfilling
|
||||||
|
a known-good corpus.
|
||||||
|
|
||||||
|
**Triage during the run.** While processing, use `markitect infospace
|
||||||
|
chapters` in another shell to see per-source entity/eval/classify counts and
|
||||||
|
mean scores — handy for spotting chapters that under-extracted or evaluated
|
||||||
|
poorly.
|
||||||
|
|
||||||
|
```
|
||||||
|
$ markitect infospace chapters
|
||||||
|
source entities evaluated classified mean_score
|
||||||
|
------------------- -------- --------- ---------- ----------
|
||||||
|
book-1-chapter-01 96 96 79 4.22
|
||||||
|
book-1-chapter-02 16 16 10 4.06
|
||||||
|
…
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## See also
|
||||||
|
|
||||||
|
- `METRICS-METHODOLOGY.md` — how each metric is computed.
|
||||||
|
- `docs/composition-guide.md` — using this infospace as a discipline for a
|
||||||
|
different domain.
|
||||||
|
- `docs/performance-notes.md` — observed timings and provider choices.
|
||||||
106
examples/infospace-with-history/docs/performance-notes.md
Normal file
106
examples/infospace-with-history/docs/performance-notes.md
Normal file
@@ -0,0 +1,106 @@
|
|||||||
|
# Performance Notes — Wealth of Nations Infospace
|
||||||
|
|
||||||
|
Observed timings, file sizes, and provider choices from the 988-entity WoN
|
||||||
|
example. These are **operational notes**, not a benchmark — numbers come
|
||||||
|
from the actual S3.3 evaluation run (2026-02-23) rather than a controlled
|
||||||
|
experiment.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Evaluation batch duration
|
||||||
|
|
||||||
|
The initial evaluation pass produced 985 `output/evaluations/*.md` files:
|
||||||
|
|
||||||
|
- First `evaluated_at`: `2026-02-23T00:11:52`
|
||||||
|
- Last `evaluated_at`: `2026-02-23T06:39:45`
|
||||||
|
- **Total wall time: ~6h 28m**
|
||||||
|
- **Effective throughput: ~2.5 entities/min** (~152 entities/hour)
|
||||||
|
|
||||||
|
Extracted from evaluation frontmatter:
|
||||||
|
```bash
|
||||||
|
grep -h '^evaluated_at:' output/evaluations/*.md | sort | sed -n '1p;$p'
|
||||||
|
```
|
||||||
|
|
||||||
|
Caveats:
|
||||||
|
- This was against OpenRouter's free tier, which applies implicit
|
||||||
|
rate-limiting and occasional retries.
|
||||||
|
- Throughput is not constant — gaps between bursts show up as plateaus
|
||||||
|
when you plot the timestamps.
|
||||||
|
- The batch was not fully parallelised; a tuned concurrent client could
|
||||||
|
likely 2–4× this throughput on a paid OpenRouter tier.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Tokens per entity (estimate)
|
||||||
|
|
||||||
|
Direct token counts are not logged in the evaluation files, but the
|
||||||
|
inputs and outputs are on disk:
|
||||||
|
|
||||||
|
- **Input per request**: evaluation schema (~3.7 KB) + entity file
|
||||||
|
(~0.7 KB median) + fixed system prompt ≈ **~1500–2500 tokens in**
|
||||||
|
- **Output per request**: structured evaluation with 5 dimensions and
|
||||||
|
rationales, median eval file 3.6 KB ≈ **~600–800 tokens out**
|
||||||
|
- **Round-trip total**: **~2000–3000 tokens per entity**
|
||||||
|
- **Batch total estimate**: 985 entities × ~2500 tokens ≈ **~2.5M tokens**
|
||||||
|
for the full pass
|
||||||
|
|
||||||
|
The constant per-entity input means the cheapest way to reduce spend on a
|
||||||
|
re-run is to narrow the targeted entities (`--entity <slug>` or
|
||||||
|
`--chapter <n>`), not to shorten the schema.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Embedding cache and collection checks
|
||||||
|
|
||||||
|
`markitect infospace check --concern redundancy` supports two similarity
|
||||||
|
backends (see `markitect/infospace/checks/redundancy.py`):
|
||||||
|
|
||||||
|
- **`word_overlap`** — the default, used when no embeddings are provided.
|
||||||
|
Pure-Python set intersection over tokenised entity text. **No LLM calls,
|
||||||
|
no cache needed.** This is what the current WoN check runs.
|
||||||
|
- **`embedding`** — active when a pre-computed `{slug: vector}` mapping is
|
||||||
|
passed in. No persistent on-disk embedding cache exists today; the
|
||||||
|
caller is responsible for computing and supplying the vectors.
|
||||||
|
|
||||||
|
Implication: the 988-entity `check` runs in seconds because it's all
|
||||||
|
word-overlap. Switching to embedding similarity would add an embedding
|
||||||
|
API pass (another ~988 requests) which is currently a manual step
|
||||||
|
outside the CLI.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Provider choice — recommendation
|
||||||
|
|
||||||
|
For the WoN dataset specifically (text-heavy entities, 5-dimension
|
||||||
|
rubric):
|
||||||
|
|
||||||
|
| Scale | Recommended provider | Rationale |
|
||||||
|
|-----------------------|----------------------------------|-----------|
|
||||||
|
| < 50 entities | `gemini/gemini-2.5-flash` | Fast default; free tier is generous enough; consistent with `markitect llm-check` out of the box. |
|
||||||
|
| 50 – 1000 entities | `openrouter` with a `:free` model (e.g. `arcee-ai/trinity-large-preview:free`) | What the S3.3 batch used; gets through 988 entities in one overnight run without cost. |
|
||||||
|
| > 1000 entities | `openrouter` with a paid small-context model, or `openai` | Free-tier rate limits start to dominate wall time; paying for higher concurrency is cheaper than calendar time. |
|
||||||
|
|
||||||
|
All providers are accepted by `markitect infospace evaluate --provider`.
|
||||||
|
The evaluation schema doesn't assume any provider-specific features.
|
||||||
|
|
||||||
|
Note on provider mixing: if part of a collection is evaluated under one
|
||||||
|
provider/model and the rest under another, `per_entity_mean` can drift
|
||||||
|
slightly (different models calibrate scores differently). For the
|
||||||
|
viability threshold of 3.5 the drift is usually negligible, but for
|
||||||
|
fine-grained outlier analysis prefer a single provider per batch.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## What is *not* measured here
|
||||||
|
|
||||||
|
- **End-to-end pipeline time** (entity extraction from raw chapters,
|
||||||
|
classification, relation graph) — only the evaluation phase is timed.
|
||||||
|
- **Memory footprint** — the full in-memory state for 988 entities is
|
||||||
|
small (< 200 MB observed), but not systematically measured.
|
||||||
|
- **Failure/retry rates** — the 985 vs 988 gap is three entities the
|
||||||
|
original run missed (plus one added later); no structured retry log
|
||||||
|
was kept.
|
||||||
|
|
||||||
|
Expanding any of these into a proper benchmark is **out of scope** for
|
||||||
|
the WoN example and should live alongside a synthetic corpus that can be
|
||||||
|
regenerated deterministically.
|
||||||
@@ -17,6 +17,8 @@ schemas:
|
|||||||
entity: schemas/economic-entity-schema-v1.0.md
|
entity: schemas/economic-entity-schema-v1.0.md
|
||||||
mapping: schemas/vsm-mapping-schema-v1.0.md
|
mapping: schemas/vsm-mapping-schema-v1.0.md
|
||||||
analysis: schemas/chapter-analysis-schema-v1.0.md
|
analysis: schemas/chapter-analysis-schema-v1.0.md
|
||||||
|
relation: schemas/relation-schema-v1.0.md
|
||||||
|
typed_entity: schemas/typed-entity-schema-v1.0.md
|
||||||
|
|
||||||
competency_questions: |
|
competency_questions: |
|
||||||
1. How does Smith's division of labour map to VSM System 1 operations?
|
1. How does Smith's division of labour map to VSM System 1 operations?
|
||||||
@@ -37,6 +39,8 @@ viability:
|
|||||||
max: 0
|
max: 0
|
||||||
granularity_entropy:
|
granularity_entropy:
|
||||||
min: 1.0
|
min: 1.0
|
||||||
|
per_entity_mean:
|
||||||
|
min: 3.5 # LLM quality score across 5 dimensions (1-5 scale)
|
||||||
|
|
||||||
pipeline:
|
pipeline:
|
||||||
stages:
|
stages:
|
||||||
|
|||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: accumulation_of_stock
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Accumulation of Stock is described as "the process by which wealth
|
||||||
|
is gathered and concentrated," emphasizing it as an ongoing activity or transformation
|
||||||
|
rather than a static entity.
|
||||||
|
vsm_rationale: This process primarily involves resource allocation and the management
|
||||||
|
of capital deployment to employ labor and undertake commercial ventures, which is
|
||||||
|
the core function of S3 management systems.
|
||||||
|
classified_at: '2026-02-23T10:39:41.206485'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Accumulation Of Stock
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Accumulation of Stock is described as "the process by which wealth is gathered and concentrated," emphasizing it as an ongoing activity or transformation rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process primarily involves resource allocation and the management of capital deployment to employ labor and undertake commercial ventures, which is the core function of S3 management systems.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: active_and_productive_stock
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: The entity "Active and Productive Stock" refers to a specific category
|
||||||
|
of capital resources (materials, tools, provisions, labour) that exists and persists
|
||||||
|
within the economy.
|
||||||
|
vsm_rationale: Active and Productive Stock directly represents the capital and resources
|
||||||
|
actively engaged in the primary productive and distributive activities of the economy,
|
||||||
|
which is the domain of S1.
|
||||||
|
classified_at: '2026-02-23T10:33:27.473504'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Active And Productive Stock
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The entity "Active and Productive Stock" refers to a specific category of capital resources (materials, tools, provisions, labour) that exists and persists within the economy.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Active and Productive Stock directly represents the capital and resources actively engaged in the primary productive and distributive activities of the economy, which is the domain of S1.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: adulteration_of_coin_standard
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S3*
|
||||||
|
type_rationale: The entity is defined as a "covert practice" and "method of currency
|
||||||
|
debasement," describing an activity or transformation rather than a static element
|
||||||
|
or rule.
|
||||||
|
vsm_rationale: Adulteration of coin standard is a fraudulent practice that directly
|
||||||
|
undermines the integrity and compliance of the coinage system, which S3* is designed
|
||||||
|
to monitor and ensure.
|
||||||
|
classified_at: '2026-02-23T10:33:32.349350'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Adulteration Of Coin Standard
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3*
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The entity is defined as a "covert practice" and "method of currency debasement," describing an activity or transformation rather than a static element or rule.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Adulteration of coin standard is a fraudulent practice that directly undermines the integrity and compliance of the coinage system, which S3* is designed to monitor and ensure.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: adulteration_of_metals
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S3*
|
||||||
|
type_rationale: The entity "Adulteration of Metals" is defined as a "fraudulent practice"
|
||||||
|
of mixing materials, which describes an activity or series of actions rather than
|
||||||
|
a static element or abstract principle.
|
||||||
|
vsm_rationale: Adulteration constitutes a breach of integrity within the metal currency
|
||||||
|
system, directly challenging the S3* function responsible for inspection, compliance,
|
||||||
|
and ensuring the authenticity of goods through mechanisms like assaying.
|
||||||
|
classified_at: '2026-02-23T10:33:38.345254'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Adulteration Of Metals
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3*
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The entity "Adulteration of Metals" is defined as a "fraudulent practice" of mixing materials, which describes an activity or series of actions rather than a static element or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Adulteration constitutes a breach of integrity within the metal currency system, directly challenging the S3* function responsible for inspection, compliance, and ensuring the authenticity of goods through mechanisms like assaying.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: adulterine_guilds
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Adulterine guilds are described as "unauthorised trade associations
|
||||||
|
that attempt to exercise corporate privileges," which represents a socially constructed
|
||||||
|
rule system or governance structure within a trade.
|
||||||
|
vsm_rationale: Adulterine guilds primarily represent an attempt to exert operational
|
||||||
|
control and influence resource allocation within a trade, and their toleration by
|
||||||
|
the crown for fines is a form of revenue management.
|
||||||
|
classified_at: '2026-02-23T10:33:47.142327'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Adulterine Guilds
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Adulterine guilds are described as "unauthorised trade associations that attempt to exercise corporate privileges," which represents a socially constructed rule system or governance structure within a trade.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Adulterine guilds primarily represent an attempt to exert operational control and influence resource allocation within a trade, and their toleration by the crown for fines is a form of revenue management.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: advanced_state_of_society
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: The "Advanced State of Society" is a persistent stage or condition
|
||||||
|
of economic development that exists and serves as a reference point for understanding
|
||||||
|
economic relationships.
|
||||||
|
vsm_rationale: The "Advanced State of Society" describes the overarching structure,
|
||||||
|
identity, and fundamental characteristics of the economic system, akin to a specific
|
||||||
|
political economy system.
|
||||||
|
classified_at: '2026-02-23T10:33:53.302785'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Advanced State Of Society
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The "Advanced State of Society" is a persistent stage or condition of economic development that exists and serves as a reference point for understanding economic relationships.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
The "Advanced State of Society" describes the overarching structure, identity, and fundamental characteristics of the economic system, akin to a specific political economy system.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: advancing_state_of_manufacture
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: The entity describes a dynamic condition of industrial development
|
||||||
|
characterized by ongoing expansion of production and demand for labour, which are
|
||||||
|
continuous activities rather than a static element.
|
||||||
|
vsm_rationale: The entity directly describes the expanding nature of primary productive
|
||||||
|
activities within the manufacturing sector, which falls under S1's domain of productive
|
||||||
|
operations.
|
||||||
|
classified_at: '2026-02-23T10:33:58.943312'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Advancing State Of Manufacture
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The entity describes a dynamic condition of industrial development characterized by ongoing expansion of production and demand for labour, which are continuous activities rather than a static element.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
The entity directly describes the expanding nature of primary productive activities within the manufacturing sector, which falls under S1's domain of productive operations.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agio_of_bank_money
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: The agio of bank money is a measurable premium or discount that exists
|
||||||
|
as a persistent market phenomenon, representing the price differential between two
|
||||||
|
forms of currency rather than being a process or relationship itself.
|
||||||
|
vsm_rationale: As a price signal that reflects the relative quality and reliability
|
||||||
|
of different currency forms, the agio serves as a coordination mechanism that helps
|
||||||
|
market participants navigate between bank money and circulating currency.
|
||||||
|
classified_at: '2026-02-23T10:39:59.578391'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agio Of Bank Money
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The agio of bank money is a measurable premium or discount that exists as a persistent market phenomenon, representing the price differential between two forms of currency rather than being a process or relationship itself.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
As a price signal that reflects the relative quality and reliability of different currency forms, the agio serves as a coordination mechanism that helps market participants navigate between bank money and circulating currency.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_capital
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural capital is a stock of resources (both fixed and circulating
|
||||||
|
capital) that persists as a tangible entity used in production, rather than being
|
||||||
|
a process or abstract principle.
|
||||||
|
vsm_rationale: Agricultural capital directly enables primary productive activities
|
||||||
|
in farming, mining, and fisheries, which are the fundamental operations that create
|
||||||
|
value in Smith's economic system.
|
||||||
|
classified_at: '2026-02-23T10:40:02.928726'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Capital
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural capital is a stock of resources (both fixed and circulating capital) that persists as a tangible entity used in production, rather than being a process or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural capital directly enables primary productive activities in farming, mining, and fisheries, which are the fundamental operations that create value in Smith's economic system.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_capital_structure
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Agricultural Capital Structure describes a socially constructed system
|
||||||
|
of ownership and organization of financial resources that establishes incentives
|
||||||
|
and governs capital deployment within farming.
|
||||||
|
vsm_rationale: The entity defines the ownership and organization of financial resources,
|
||||||
|
which directly determines the allocation and operational control of capital within
|
||||||
|
agricultural production, aligning with S3's focus on resource management.
|
||||||
|
classified_at: '2026-02-23T10:34:04.081497'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Capital Structure
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Capital Structure describes a socially constructed system of ownership and organization of financial resources that establishes incentives and governs capital deployment within farming.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
The entity defines the ownership and organization of financial resources, which directly determines the allocation and operational control of capital within agricultural production, aligning with S3's focus on resource management.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_comparative_advantage
|
||||||
|
entity_type: Principle
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: Agricultural comparative advantage represents an abstract economic
|
||||||
|
law about relative efficiency that holds across different regions and contexts,
|
||||||
|
making it a theoretical principle rather than a concrete entity or process.
|
||||||
|
vsm_rationale: This principle operates within the intelligence system by guiding how
|
||||||
|
economies adapt to environmental conditions and scan for optimal specialization
|
||||||
|
opportunities in the international division of agricultural labor.
|
||||||
|
classified_at: '2026-02-23T10:40:06.319634'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Comparative Advantage
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Principle
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural comparative advantage represents an abstract economic law about relative efficiency that holds across different regions and contexts, making it a theoretical principle rather than a concrete entity or process.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This principle operates within the intelligence system by guiding how economies adapt to environmental conditions and scan for optimal specialization opportunities in the international division of agricultural labor.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_cultivation
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural cultivation is defined as "the practice of preparing
|
||||||
|
and using land for growing crops and raising livestock" with activities "from soil
|
||||||
|
preparation to harvest," making it clearly a flow of activities and transformations
|
||||||
|
with duration rather than something that exists independently.
|
||||||
|
vsm_rationale: Agricultural cultivation represents the primary productive operations
|
||||||
|
that transform land, labor, and capital into crops and livestock, which is the fundamental
|
||||||
|
work of S1 as the system responsible for productive activities.
|
||||||
|
classified_at: '2026-02-23T10:40:15.846618'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Cultivation
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural cultivation is defined as "the practice of preparing and using land for growing crops and raising livestock" with activities "from soil preparation to harvest," making it clearly a flow of activities and transformations with duration rather than something that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural cultivation represents the primary productive operations that transform land, labor, and capital into crops and livestock, which is the fundamental work of S1 as the system responsible for productive activities.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_cultivation_at_farmer_expense
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: This represents a socially constructed rule system that governs the
|
||||||
|
relationship between landlords and tenant farmers, establishing norms around capital
|
||||||
|
provision, rent payment, and tenure security.
|
||||||
|
vsm_rationale: This system directly organizes primary agricultural production activities
|
||||||
|
by structuring how farming operations are conducted and capitalized at the most
|
||||||
|
basic productive level.
|
||||||
|
classified_at: '2026-02-23T10:40:09.817002'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Cultivation At Farmer Expense
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
This represents a socially constructed rule system that governs the relationship between landlords and tenant farmers, establishing norms around capital provision, rent payment, and tenure security.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This system directly organizes primary agricultural production activities by structuring how farming operations are conducted and capitalized at the most basic productive level.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_cultivation_at_proprietor_expense
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: This represents a socially constructed rule system that governs the
|
||||||
|
relationship between landlords and cultivators, defining who provides capital, who
|
||||||
|
bears risk, and how produce is distributed.
|
||||||
|
vsm_rationale: This system directly organizes primary productive activities in agriculture,
|
||||||
|
determining how farming operations are structured and executed at the foundational
|
||||||
|
level of economic production.
|
||||||
|
classified_at: '2026-02-23T10:40:12.639287'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Cultivation At Proprietor Expense
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
This represents a socially constructed rule system that governs the relationship between landlords and cultivators, defining who provides capital, who bears risk, and how produce is distributed.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This system directly organizes primary productive activities in agriculture, determining how farming operations are structured and executed at the foundational level of economic production.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_demand
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural demand is a persistent market force that exists as an
|
||||||
|
aggregate of consumer preferences and needs for agricultural products, functioning
|
||||||
|
as a stock of purchasing power directed toward farm produce.
|
||||||
|
vsm_rationale: Agricultural demand operates as a coordination mechanism that generates
|
||||||
|
price signals to farmers and landowners, helping to prevent oscillations between
|
||||||
|
overproduction and underproduction in agricultural markets.
|
||||||
|
classified_at: '2026-02-23T10:40:18.565060'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Demand
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural demand is a persistent market force that exists as an aggregate of consumer preferences and needs for agricultural products, functioning as a stock of purchasing power directed toward farm produce.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural demand operates as a coordination mechanism that generates price signals to farmers and landowners, helping to prevent oscillations between overproduction and underproduction in agricultural markets.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_development_constraints
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Development Constraints represents a comprehensive system
|
||||||
|
of socially constructed rules, laws, and governance structures (primogeniture, entails,
|
||||||
|
servile labor systems) that collectively formed the institutional framework governing
|
||||||
|
agricultural production.
|
||||||
|
vsm_rationale: These constraints operated at the level of primary agricultural operations
|
||||||
|
by directly limiting the productive activities, investment incentives, and improvement
|
||||||
|
possibilities within the fundamental agricultural sector that formed the base of
|
||||||
|
the economic system.
|
||||||
|
classified_at: '2026-02-23T10:40:22.983960'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Development Constraints
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Development Constraints represents a comprehensive system of socially constructed rules, laws, and governance structures (primogeniture, entails, servile labor systems) that collectively formed the institutional framework governing agricultural production.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
These constraints operated at the level of primary agricultural operations by directly limiting the productive activities, investment incentives, and improvement possibilities within the fundamental agricultural sector that formed the base of the economic system.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_development_sequence
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: The Agricultural Development Sequence is a historical progression
|
||||||
|
and transformation over time from primitive to advanced farming systems, making
|
||||||
|
it fundamentally a process rather than a static entity.
|
||||||
|
vsm_rationale: This sequence represents Smith's analysis of how agricultural systems
|
||||||
|
adapt and evolve in response to changing legal, social, and economic environments,
|
||||||
|
which is the intelligence function of scanning and understanding systemic adaptation
|
||||||
|
patterns.
|
||||||
|
classified_at: '2026-02-23T10:40:26.001121'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Development Sequence
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The Agricultural Development Sequence is a historical progression and transformation over time from primitive to advanced farming systems, making it fundamentally a process rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This sequence represents Smith's analysis of how agricultural systems adapt and evolve in response to changing legal, social, and economic environments, which is the intelligence function of scanning and understanding systemic adaptation patterns.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_economic_potential
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Economic Potential represents a measurable stock or capacity
|
||||||
|
that exists as an inherent property of agricultural regions, functioning as a noun-like
|
||||||
|
entity that can be quantified and compared across different territories.
|
||||||
|
vsm_rationale: This entity belongs to S1 because it represents the fundamental productive
|
||||||
|
capacity of primary agricultural operations, which form the foundation of economic
|
||||||
|
activity that Smith analyzes throughout his work.
|
||||||
|
classified_at: '2026-02-23T10:40:29.696584'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Economic Potential
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Economic Potential represents a measurable stock or capacity that exists as an inherent property of agricultural regions, functioning as a noun-like entity that can be quantified and compared across different territories.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This entity belongs to S1 because it represents the fundamental productive capacity of primary agricultural operations, which form the foundation of economic activity that Smith analyzes throughout his work.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_efficiency
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural efficiency is a measurable attribute or property of farming
|
||||||
|
operations that persists as a characteristic of the agricultural system, rather
|
||||||
|
than being an activity or process itself.
|
||||||
|
vsm_rationale: Agricultural efficiency directly relates to the effectiveness of primary
|
||||||
|
productive activities in farming operations, which constitute the fundamental operational
|
||||||
|
level of economic production.
|
||||||
|
classified_at: '2026-02-23T10:40:32.562129'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Efficiency
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural efficiency is a measurable attribute or property of farming operations that persists as a characteristic of the agricultural system, rather than being an activity or process itself.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural efficiency directly relates to the effectiveness of primary productive activities in farming operations, which constitute the fundamental operational level of economic production.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_improvement
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural improvement is fundamentally an activity or transformation
|
||||||
|
that happens over time to enhance farming practices and land productivity, rather
|
||||||
|
than something that exists as a static entity.
|
||||||
|
vsm_rationale: Agricultural improvement represents a primary productive activity that
|
||||||
|
directly enhances the fundamental operations of farming and land cultivation within
|
||||||
|
the economic system.
|
||||||
|
classified_at: '2026-02-23T10:40:43.248434'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Improvement
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural improvement is fundamentally an activity or transformation that happens over time to enhance farming practices and land productivity, rather than something that exists as a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural improvement represents a primary productive activity that directly enhances the fundamental operations of farming and land cultivation within the economic system.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_improvement_discouragement
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: Agricultural Improvement Discouragement represents a comprehensive
|
||||||
|
system of feudal rules, laws, and social norms (primogeniture, entails, servile
|
||||||
|
labor) that governed economic behavior rather than being a physical entity, process,
|
||||||
|
or abstract principle.
|
||||||
|
vsm_rationale: This institutional framework operates at the S5 level because it defines
|
||||||
|
the fundamental identity and purpose of the feudal economic system, establishing
|
||||||
|
the ultimate authority structures and policy orientations that shaped all lower-level
|
||||||
|
economic activities.
|
||||||
|
classified_at: '2026-02-23T10:40:36.572287'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Improvement Discouragement
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Improvement Discouragement represents a comprehensive system of feudal rules, laws, and social norms (primogeniture, entails, servile labor) that governed economic behavior rather than being a physical entity, process, or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This institutional framework operates at the S5 level because it defines the fundamental identity and purpose of the feudal economic system, establishing the ultimate authority structures and policy orientations that shaped all lower-level economic activities.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_improvement_foundation
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: An "Agricultural Improvement Foundation" represents a socially constructed
|
||||||
|
organizational structure designed to govern and systematize efforts toward agricultural
|
||||||
|
enhancement, fitting the definition of an institution as a rule system or governance
|
||||||
|
structure.
|
||||||
|
vsm_rationale: As a foundation focused on agricultural improvement, this entity would
|
||||||
|
primarily function in resource allocation and operational control by directing capital
|
||||||
|
and resources toward productive agricultural activities, which aligns with S3 management
|
||||||
|
functions.
|
||||||
|
classified_at: '2026-02-23T10:40:40.117120'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Improvement Foundation
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
An "Agricultural Improvement Foundation" represents a socially constructed organizational structure designed to govern and systematize efforts toward agricultural enhancement, fitting the definition of an institution as a rule system or governance structure.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
As a foundation focused on agricultural improvement, this entity would primarily function in resource allocation and operational control by directing capital and resources toward productive agricultural activities, which aligns with S3 management functions.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_labour
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural labour is an activity or flow of work that happens over
|
||||||
|
time in farming and food production, rather than something that exists independently
|
||||||
|
as a stock or agent.
|
||||||
|
vsm_rationale: Agricultural labour represents the primary productive operations that
|
||||||
|
transform inputs into food and agricultural outputs, which is the core function
|
||||||
|
of S1 in the viable system model.
|
||||||
|
classified_at: '2026-02-23T10:40:46.305975'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Labour
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural labour is an activity or flow of work that happens over time in farming and food production, rather than something that exists independently as a stock or agent.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural labour represents the primary productive operations that transform inputs into food and agricultural outputs, which is the core function of S1 in the viable system model.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_cost_structure
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural Market Access Cost Structure is a composite stock of
|
||||||
|
various cost components (transportation costs, trade barriers, taxes, institutional
|
||||||
|
restrictions) that exists as a persistent barrier affecting market participation.
|
||||||
|
vsm_rationale: This cost structure primarily functions as a coordination mechanism
|
||||||
|
that determines whether price signals can effectively connect agricultural producers
|
||||||
|
to markets, making it fundamentally about the transmission and effectiveness of
|
||||||
|
market coordination.
|
||||||
|
classified_at: '2026-02-23T10:40:49.860954'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Cost Structure
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Access Cost Structure is a composite stock of various cost components (transportation costs, trade barriers, taxes, institutional restrictions) that exists as a persistent barrier affecting market participation.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This cost structure primarily functions as a coordination mechanism that determines whether price signals can effectively connect agricultural producers to markets, making it fundamentally about the transmission and effectiveness of market coordination.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_development_prerequisites
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Agricultural Market Access Development Prerequisites represents a
|
||||||
|
socially constructed rule system encompassing property rights, legal frameworks,
|
||||||
|
and governance structures that must be established to enable effective agricultural
|
||||||
|
markets.
|
||||||
|
vsm_rationale: These prerequisites function as management-level institutional arrangements
|
||||||
|
that allocate resources and control operations by establishing the foundational
|
||||||
|
conditions under which agricultural production and exchange can occur efficiently.
|
||||||
|
classified_at: '2026-02-23T10:40:52.244518'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Development Prerequisites
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Access Development Prerequisites represents a socially constructed rule system encompassing property rights, legal frameworks, and governance structures that must be established to enable effective agricultural markets.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
These prerequisites function as management-level institutional arrangements that allocate resources and control operations by establishing the foundational conditions under which agricultural production and exchange can occur efficiently.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_development_sequence
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: This entity represents a temporal transformation and evolutionary
|
||||||
|
activity ("historical progression") that unfolds over time rather than a static
|
||||||
|
structure or rule, making it fundamentally a process of market development.
|
||||||
|
vsm_rationale: This process involves scanning and adapting to environmental changes
|
||||||
|
in institutional frameworks and trade barriers, representing the intelligence function
|
||||||
|
that enables the economic system to evolve and adapt its market structures over
|
||||||
|
time.
|
||||||
|
classified_at: '2026-02-23T10:40:56.674360'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Development Sequence
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
This entity represents a temporal transformation and evolutionary activity ("historical progression") that unfolds over time rather than a static structure or rule, making it fundamentally a process of market development.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process involves scanning and adapting to environmental changes in institutional frameworks and trade barriers, representing the intelligence function that enables the economic system to evolve and adapt its market structures over time.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_gradient
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: The Agricultural Market Access Gradient represents a structural dependency
|
||||||
|
between geographical/institutional factors and economic outcomes, functioning as
|
||||||
|
a causal mechanism that connects location-based advantages to regional development
|
||||||
|
patterns.
|
||||||
|
vsm_rationale: This gradient serves as an intelligence function by revealing how environmental
|
||||||
|
scanning of geographical and institutional conditions determines adaptive capacity
|
||||||
|
for different regions to engage with broader economic systems.
|
||||||
|
classified_at: '2026-02-23T10:41:00.548872'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Gradient
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The Agricultural Market Access Gradient represents a structural dependency between geographical/institutional factors and economic outcomes, functioning as a causal mechanism that connects location-based advantages to regional development patterns.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This gradient serves as an intelligence function by revealing how environmental scanning of geographical and institutional conditions determines adaptive capacity for different regions to engage with broader economic systems.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_inequality
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural Market Access Inequality represents a structural dependency
|
||||||
|
between geographical/institutional factors and farmers' market opportunities, functioning
|
||||||
|
as a causal link that determines differential outcomes rather than being an entity
|
||||||
|
that exists independently.
|
||||||
|
vsm_rationale: This inequality operates primarily through price signal mechanisms
|
||||||
|
and market coordination failures, where transportation costs and institutional barriers
|
||||||
|
create systematic disparities in the prices farmers can obtain for their produce
|
||||||
|
across different regions.
|
||||||
|
classified_at: '2026-02-23T10:41:04.667548'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Inequality
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Access Inequality represents a structural dependency between geographical/institutional factors and farmers' market opportunities, functioning as a causal link that determines differential outcomes rather than being an entity that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This inequality operates primarily through price signal mechanisms and market coordination failures, where transportation costs and institutional barriers create systematic disparities in the prices farmers can obtain for their produce across different regions.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_access_opportunity_cost
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: Agricultural Market Access Opportunity Cost represents a measurable
|
||||||
|
economic value that exists as a consequence of market barriers, functioning as a
|
||||||
|
persistent stock of foregone wealth rather than a process or relationship.
|
||||||
|
vsm_rationale: This entity operates within S4 Intelligence as it represents the analytical
|
||||||
|
framework Smith uses to scan and understand how environmental constraints (institutional
|
||||||
|
barriers, geography) create adaptation challenges that prevent optimal economic
|
||||||
|
outcomes.
|
||||||
|
classified_at: '2026-02-23T10:41:08.777369'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Access Opportunity Cost
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Access Opportunity Cost represents a measurable economic value that exists as a consequence of market barriers, functioning as a persistent stock of foregone wealth rather than a process or relationship.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This entity operates within S4 Intelligence as it represents the analytical framework Smith uses to scan and understand how environmental constraints (institutional barriers, geography) create adaptation challenges that prevent optimal economic outcomes.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_communication_channels
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural Market Communication Channels are information networks
|
||||||
|
that exist as persistent infrastructure for transmitting market data, making them
|
||||||
|
a stock or artifact that exists independently rather than a process or activity.
|
||||||
|
vsm_rationale: These channels primarily function to transmit price signals and demand
|
||||||
|
conditions that coordinate agricultural markets by preventing oscillations between
|
||||||
|
supply and demand, which is the core anti-oscillation function of S2.
|
||||||
|
classified_at: '2026-02-23T10:41:11.869786'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Communication Channels
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Communication Channels are information networks that exist as persistent infrastructure for transmitting market data, making them a stock or artifact that exists independently rather than a process or activity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
These channels primarily function to transmit price signals and demand conditions that coordinate agricultural markets by preventing oscillations between supply and demand, which is the core anti-oscillation function of S2.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_integration
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural market integration is an ongoing activity of connecting
|
||||||
|
markets through trade and transportation that unfolds over time, rather than a static
|
||||||
|
entity that exists independently.
|
||||||
|
vsm_rationale: This process primarily functions as a coordination mechanism that enables
|
||||||
|
price equalization across regions through market signals, which is the core anti-oscillation
|
||||||
|
function of S2.
|
||||||
|
classified_at: '2026-02-23T10:41:15.173110'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Integration
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural market integration is an ongoing activity of connecting markets through trade and transportation that unfolds over time, rather than a static entity that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process primarily functions as a coordination mechanism that enables price equalization across regions through market signals, which is the core anti-oscillation function of S2.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_market_size_threshold
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural Market Size Threshold represents a measurable stock or
|
||||||
|
quantity (minimum market size) that exists as a concrete economic parameter determining
|
||||||
|
when specialization becomes viable.
|
||||||
|
vsm_rationale: This threshold functions as a coordination mechanism that determines
|
||||||
|
when price signals and market forces can effectively support specialized agricultural
|
||||||
|
production and division of labor.
|
||||||
|
classified_at: '2026-02-23T10:41:18.346754'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Market Size Threshold
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Market Size Threshold represents a measurable stock or quantity (minimum market size) that exists as a concrete economic parameter determining when specialization becomes viable.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This threshold functions as a coordination mechanism that determines when price signals and market forces can effectively support specialized agricultural production and division of labor.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_opportunity_cost
|
||||||
|
entity_type: Principle
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Agricultural Opportunity Cost represents an abstract economic law
|
||||||
|
about the value of foregone alternatives that applies universally across different
|
||||||
|
agricultural contexts and time periods.
|
||||||
|
vsm_rationale: This principle operates primarily in the management system where farmers
|
||||||
|
must allocate scarce land and labor resources among competing uses, making operational
|
||||||
|
control decisions about production methods and crop selection.
|
||||||
|
classified_at: '2026-02-23T10:41:21.877352'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Opportunity Cost
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Principle
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Opportunity Cost represents an abstract economic law about the value of foregone alternatives that applies universally across different agricultural contexts and time periods.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This principle operates primarily in the management system where farmers must allocate scarce land and labor resources among competing uses, making operational control decisions about production methods and crop selection.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_ceilings
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: Agricultural price ceilings are a socially constructed rule system
|
||||||
|
imposed by government authority to govern market behavior, making them an institutional
|
||||||
|
framework rather than a natural economic element or process.
|
||||||
|
vsm_rationale: As government-imposed maximum prices that reflect policy decisions
|
||||||
|
about protecting consumer interests versus market efficiency, agricultural price
|
||||||
|
ceilings operate at the level of ultimate authority and purpose that defines the
|
||||||
|
economic system's identity and values.
|
||||||
|
classified_at: '2026-02-23T10:41:24.954626'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Ceilings
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price ceilings are a socially constructed rule system imposed by government authority to govern market behavior, making them an institutional framework rather than a natural economic element or process.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
As government-imposed maximum prices that reflect policy decisions about protecting consumer interests versus market efficiency, agricultural price ceilings operate at the level of ultimate authority and purpose that defines the economic system's identity and values.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_differential
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: The agricultural price differential represents a structural dependency
|
||||||
|
between market proximity and economic advantage, functioning as a causal mechanism
|
||||||
|
that links transportation costs to producer profits.
|
||||||
|
vsm_rationale: This price differential operates as a coordination mechanism that transmits
|
||||||
|
location-based cost advantages through the price system, helping to coordinate the
|
||||||
|
spatial allocation of agricultural resources around urban markets.
|
||||||
|
classified_at: '2026-02-23T10:41:28.540951'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Differential
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The agricultural price differential represents a structural dependency between market proximity and economic advantage, functioning as a causal mechanism that links transportation costs to producer profits.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This price differential operates as a coordination mechanism that transmits location-based cost advantages through the price system, helping to coordinate the spatial allocation of agricultural resources around urban markets.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_discovery
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price discovery is described as "the process by which
|
||||||
|
market prices for agricultural products are established," emphasizing it as an ongoing
|
||||||
|
activity with duration rather than a static entity.
|
||||||
|
vsm_rationale: This process operates as a coordination mechanism that uses price signals
|
||||||
|
to prevent market oscillations and coordinate the interaction between buyers and
|
||||||
|
sellers in agricultural markets.
|
||||||
|
classified_at: '2026-02-23T10:41:30.938808'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Discovery
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price discovery is described as "the process by which market prices for agricultural products are established," emphasizing it as an ongoing activity with duration rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process operates as a coordination mechanism that uses price signals to prevent market oscillations and coordinate the interaction between buyers and sellers in agricultural markets.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_discrimination
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price discrimination is an ongoing activity of charging
|
||||||
|
different prices across markets rather than a static entity, making it a process
|
||||||
|
that unfolds over time through seller behavior.
|
||||||
|
vsm_rationale: This pricing activity functions as a coordination mechanism that responds
|
||||||
|
to market conditions and transportation costs to manage price signals across different
|
||||||
|
markets, which is the core function of S2 anti-oscillation and price coordination.
|
||||||
|
classified_at: '2026-02-23T10:41:34.481691'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Discrimination
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price discrimination is an ongoing activity of charging different prices across markets rather than a static entity, making it a process that unfolds over time through seller behavior.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This pricing activity functions as a coordination mechanism that responds to market conditions and transportation costs to manage price signals across different markets, which is the core function of S2 anti-oscillation and price coordination.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_elasticity
|
||||||
|
entity_type: Principle
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price elasticity is an abstract economic law that describes
|
||||||
|
how markets consistently respond to price changes across different contexts and
|
||||||
|
time periods.
|
||||||
|
vsm_rationale: This principle operates primarily within the coordination system by
|
||||||
|
governing how price signals translate into quantity adjustments, serving as a fundamental
|
||||||
|
mechanism for market coordination and anti-oscillation behavior.
|
||||||
|
classified_at: '2026-02-23T10:41:37.063488'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Elasticity
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Principle
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price elasticity is an abstract economic law that describes how markets consistently respond to price changes across different contexts and time periods.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This principle operates primarily within the coordination system by governing how price signals translate into quantity adjustments, serving as a fundamental mechanism for market coordination and anti-oscillation behavior.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_equalization
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural Price Equalization is a market mechanism that actively
|
||||||
|
operates over time to align prices across different locations, representing an ongoing
|
||||||
|
activity rather than a static entity or abstract principle.
|
||||||
|
vsm_rationale: This mechanism functions as a coordination system that uses price signals
|
||||||
|
to prevent oscillations and maintain market stability by incorporating transportation
|
||||||
|
costs into price differentials across geographic locations.
|
||||||
|
classified_at: '2026-02-23T10:41:40.169776'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Equalization
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Price Equalization is a market mechanism that actively operates over time to align prices across different locations, representing an ongoing activity rather than a static entity or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This mechanism functions as a coordination system that uses price signals to prevent oscillations and maintain market stability by incorporating transportation costs into price differentials across geographic locations.
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_floors
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: Agricultural price floors are a socially constructed rule system established
|
||||||
|
by government to govern market behavior through minimum pricing requirements.
|
||||||
|
vsm_rationale: Price floors represent policy-level decisions about the fundamental
|
||||||
|
purpose and identity of economic intervention, reflecting ultimate governmental
|
||||||
|
authority over market structures.
|
||||||
|
classified_at: '2026-02-23T10:41:43.377347'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Floors
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price floors are a socially constructed rule system established by government to govern market behavior through minimum pricing requirements.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Price floors represent policy-level decisions about the fundamental purpose and identity of economic intervention, reflecting ultimate governmental authority over market structures.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_mechanism
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: The agricultural price mechanism is described as a "market process"
|
||||||
|
that involves ongoing activities of price determination through supply and demand
|
||||||
|
interactions, making it a flow or activity rather than a static entity.
|
||||||
|
vsm_rationale: This mechanism primarily functions as a coordination system that uses
|
||||||
|
price signals to communicate information about scarcity and abundance, preventing
|
||||||
|
oscillations between oversupply and shortage in agricultural markets.
|
||||||
|
classified_at: '2026-02-23T10:41:46.176833'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Mechanism
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The agricultural price mechanism is described as a "market process" that involves ongoing activities of price determination through supply and demand interactions, making it a flow or activity rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This mechanism primarily functions as a coordination system that uses price signals to communicate information about scarcity and abundance, preventing oscillations between oversupply and shortage in agricultural markets.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_regulation
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Agricultural price regulation represents a socially constructed rule
|
||||||
|
system that governs market behavior through formal government mechanisms and legal
|
||||||
|
frameworks.
|
||||||
|
vsm_rationale: This entity operates primarily in the management system by controlling
|
||||||
|
resource allocation and operational decisions in agricultural markets through direct
|
||||||
|
price intervention mechanisms.
|
||||||
|
classified_at: '2026-02-23T10:41:48.637652'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Regulation
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price regulation represents a socially constructed rule system that governs market behavior through formal government mechanisms and legal frameworks.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This entity operates primarily in the management system by controlling resource allocation and operational decisions in agricultural markets through direct price intervention mechanisms.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_stability
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price stability is a measurable state or condition that
|
||||||
|
can exist independently as a characteristic of markets, making it a stock-like element
|
||||||
|
rather than a process or relation.
|
||||||
|
vsm_rationale: Price stability functions as a coordination mechanism that dampens
|
||||||
|
market oscillations and provides consistent signals for economic decision-making,
|
||||||
|
which is the core anti-oscillation function of S2.
|
||||||
|
classified_at: '2026-02-23T10:41:51.650766'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Stability
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price stability is a measurable state or condition that can exist independently as a characteristic of markets, making it a stock-like element rather than a process or relation.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Price stability functions as a coordination mechanism that dampens market oscillations and provides consistent signals for economic decision-making, which is the core anti-oscillation function of S2.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_transmission
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price transmission is described as "the process by which
|
||||||
|
price changes in one agricultural market or region affect prices in other markets,"
|
||||||
|
clearly identifying it as an activity or flow that happens over time rather than
|
||||||
|
something that exists independently.
|
||||||
|
vsm_rationale: This process operates through price signals that coordinate markets
|
||||||
|
by transmitting information about supply and demand conditions across regions, which
|
||||||
|
is the core coordination function of S2 in preventing oscillations and maintaining
|
||||||
|
market equilibrium.
|
||||||
|
classified_at: '2026-02-23T10:41:55.918616'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Transmission
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price transmission is described as "the process by which price changes in one agricultural market or region affect prices in other markets," clearly identifying it as an activity or flow that happens over time rather than something that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process operates through price signals that coordinate markets by transmitting information about supply and demand conditions across regions, which is the core coordination function of S2 in preventing oscillations and maintaining market equilibrium.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_price_volatility
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S2
|
||||||
|
type_rationale: Agricultural price volatility is a measurable characteristic or property
|
||||||
|
of agricultural markets that persists as an observable phenomenon, making it a stock-like
|
||||||
|
element rather than a process or relation.
|
||||||
|
vsm_rationale: Price volatility functions as part of the coordination system that
|
||||||
|
provides market signals about supply and demand conditions, helping to regulate
|
||||||
|
economic oscillations in agricultural markets.
|
||||||
|
classified_at: '2026-02-23T10:41:59.184645'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Price Volatility
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S2
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural price volatility is a measurable characteristic or property of agricultural markets that persists as an observable phenomenon, making it a stock-like element rather than a process or relation.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Price volatility functions as part of the coordination system that provides market signals about supply and demand conditions, helping to regulate economic oscillations in agricultural markets.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_productivity
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural productivity is a measurable characteristic or capacity
|
||||||
|
of agricultural land and labor that persists as a stock-like property, representing
|
||||||
|
the efficiency potential that exists independently rather than being a process or
|
||||||
|
activity itself.
|
||||||
|
vsm_rationale: Agricultural productivity directly relates to the primary productive
|
||||||
|
operations of the economy, as it measures the efficiency of the fundamental agricultural
|
||||||
|
labor and land use that constitutes the basic productive activities Smith analyzes.
|
||||||
|
classified_at: '2026-02-23T10:42:07.242630'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Productivity
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural productivity is a measurable characteristic or capacity of agricultural land and labor that persists as a stock-like property, representing the efficiency potential that exists independently rather than being a process or activity itself.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural productivity directly relates to the primary productive operations of the economy, as it measures the efficiency of the fundamental agricultural labor and land use that constitutes the basic productive activities Smith analyzes.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_productivity_limits
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Productivity Limits represents a structural dependency
|
||||||
|
between institutional arrangements (labor systems, capital ownership) and farming
|
||||||
|
efficiency outcomes, functioning as a causal mechanism that connects different organizational
|
||||||
|
forms to their productivity consequences.
|
||||||
|
vsm_rationale: This entity operates within S1 as it directly constrains and shapes
|
||||||
|
the primary productive activities of agricultural labor, determining how effectively
|
||||||
|
farming operations can generate output.
|
||||||
|
classified_at: '2026-02-23T10:42:03.110025'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Productivity Limits
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Productivity Limits represents a structural dependency between institutional arrangements (labor systems, capital ownership) and farming efficiency outcomes, functioning as a causal mechanism that connects different organizational forms to their productivity consequences.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This entity operates within S1 as it directly constrains and shapes the primary productive activities of agricultural labor, determining how effectively farming operations can generate output.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_security_gradient
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: The Agricultural Security Gradient represents a structural dependency
|
||||||
|
between legal protection levels and agricultural improvement outcomes, functioning
|
||||||
|
as a causal mechanism that connects different tenure systems to their economic results.
|
||||||
|
vsm_rationale: This gradient operates at the policy level by establishing the fundamental
|
||||||
|
relationship between legal frameworks and economic outcomes, representing how different
|
||||||
|
governance structures regarding property rights determine the overall purpose and
|
||||||
|
identity of agricultural systems.
|
||||||
|
classified_at: '2026-02-23T10:42:10.707477'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Security Gradient
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The Agricultural Security Gradient represents a structural dependency between legal protection levels and agricultural improvement outcomes, functioning as a causal mechanism that connects different tenure systems to their economic results.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This gradient operates at the policy level by establishing the fundamental relationship between legal frameworks and economic outcomes, representing how different governance structures regarding property rights determine the overall purpose and identity of agricultural systems.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_spatial_inequality
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Spatial Inequality represents a persistent economic condition
|
||||||
|
or state that exists as a measurable disparity between regions, rather than being
|
||||||
|
a process, relationship, or rule system.
|
||||||
|
vsm_rationale: This inequality fundamentally concerns the primary productive operations
|
||||||
|
of agriculture and the differential outcomes these operations produce across different
|
||||||
|
spatial locations.
|
||||||
|
classified_at: '2026-02-23T10:42:14.138288'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Spatial Inequality
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Spatial Inequality represents a persistent economic condition or state that exists as a measurable disparity between regions, rather than being a process, relationship, or rule system.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This inequality fundamentally concerns the primary productive operations of agriculture and the differential outcomes these operations produce across different spatial locations.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_specialization
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural specialization is described as "the concentration of
|
||||||
|
agricultural production" which represents an ongoing activity or transformation
|
||||||
|
in how farming is organized and conducted, rather than a static entity that exists
|
||||||
|
independently.
|
||||||
|
vsm_rationale: Agricultural specialization operates as a primary productive activity
|
||||||
|
that directly transforms how crops and livestock are produced, making it a core
|
||||||
|
operational process within the primary production system.
|
||||||
|
classified_at: '2026-02-23T10:42:17.253509'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Specialization
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural specialization is described as "the concentration of agricultural production" which represents an ongoing activity or transformation in how farming is organized and conducted, rather than a static entity that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural specialization operates as a primary productive activity that directly transforms how crops and livestock are produced, making it a core operational process within the primary production system.
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_stock
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Stock is a tangible collection of capital goods (livestock,
|
||||||
|
implements, seeds) that exists as a persistent stock necessary for farming operations.
|
||||||
|
vsm_rationale: This stock directly enables primary productive activities in agriculture,
|
||||||
|
which represents the fundamental operational level of economic production in Smith's
|
||||||
|
framework.
|
||||||
|
classified_at: '2026-02-23T10:42:21.075344'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Stock
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Stock is a tangible collection of capital goods (livestock, implements, seeds) that exists as a persistent stock necessary for farming operations.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This stock directly enables primary productive activities in agriculture, which represents the fundamental operational level of economic production in Smith's framework.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_supply
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural supply represents a measurable quantity of products that
|
||||||
|
exists as a stock in the market at any given time, making it a persistent entity
|
||||||
|
rather than a process or relationship.
|
||||||
|
vsm_rationale: Agricultural supply constitutes the fundamental productive output from
|
||||||
|
primary agricultural operations, which are the core productive activities that form
|
||||||
|
the foundation of the economic system.
|
||||||
|
classified_at: '2026-02-23T10:42:24.047470'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Supply
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural supply represents a measurable quantity of products that exists as a stock in the market at any given time, making it a persistent entity rather than a process or relationship.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural supply constitutes the fundamental productive output from primary agricultural operations, which are the core productive activities that form the foundation of the economic system.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_surplus
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural surplus is a tangible stock of excess produce that exists
|
||||||
|
as a measurable quantity beyond subsistence requirements, making it a persistent
|
||||||
|
entity rather than a process or abstract principle.
|
||||||
|
vsm_rationale: Agricultural surplus emerges directly from primary productive activities
|
||||||
|
in farming and cultivation, representing the fundamental output of agricultural
|
||||||
|
operations that enables all other economic activity.
|
||||||
|
classified_at: '2026-02-23T10:42:30.142977'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Surplus
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural surplus is a tangible stock of excess produce that exists as a measurable quantity beyond subsistence requirements, making it a persistent entity rather than a process or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural surplus emerges directly from primary productive activities in farming and cultivation, representing the fundamental output of agricultural operations that enables all other economic activity.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_surplus_determination
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S3
|
||||||
|
type_rationale: Agricultural surplus determination is an economic calculation and
|
||||||
|
activity that happens over time to assess excess production, rather than being a
|
||||||
|
static entity that exists independently.
|
||||||
|
vsm_rationale: This determination process involves the fundamental management function
|
||||||
|
of resource allocation by calculating how much agricultural output can be allocated
|
||||||
|
beyond subsistence needs to support urban development and commercial activities.
|
||||||
|
classified_at: '2026-02-23T10:42:27.311214'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Surplus Determination
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural surplus determination is an economic calculation and activity that happens over time to assess excess production, rather than being a static entity that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This determination process involves the fundamental management function of resource allocation by calculating how much agricultural output can be allocated beyond subsistence needs to support urban development and commercial activities.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_systems_of_political_economy
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: Agricultural Systems of Political Economy represents a socially constructed
|
||||||
|
rule system and governance structure that establishes norms about how economic value
|
||||||
|
should be understood and policy should be directed.
|
||||||
|
vsm_rationale: This system operates at the S5 level because it defines the fundamental
|
||||||
|
identity and purpose of political economy itself, establishing the ultimate authority
|
||||||
|
and philosophical foundation for how a nation should organize its economic activities.
|
||||||
|
classified_at: '2026-02-23T10:42:33.295942'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Systems Of Political Economy
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Systems of Political Economy represents a socially constructed rule system and governance structure that establishes norms about how economic value should be understood and policy should be directed.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This system operates at the S5 level because it defines the fundamental identity and purpose of political economy itself, establishing the ultimate authority and philosophical foundation for how a nation should organize its economic activities.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_technology
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural technology represents a collection of persistent tools,
|
||||||
|
techniques, and methods that exist as tangible and intangible assets used in farming
|
||||||
|
operations, making it a stock or artifact that endures over time.
|
||||||
|
vsm_rationale: Agricultural technology directly enables and enhances the primary productive
|
||||||
|
activities of farming, which constitute the fundamental operational work of agricultural
|
||||||
|
production in the economic system.
|
||||||
|
classified_at: '2026-02-23T10:42:39.582919'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Technology
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural technology represents a collection of persistent tools, techniques, and methods that exist as tangible and intangible assets used in farming operations, making it a stock or artifact that endures over time.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural technology directly enables and enhances the primary productive activities of farming, which constitute the fundamental operational work of agricultural production in the economic system.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_technology_adoption
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural Technology Adoption represents an ongoing activity or
|
||||||
|
transformation where new technologies are implemented and integrated into agricultural
|
||||||
|
practices over time, making it a process rather than a static entity.
|
||||||
|
vsm_rationale: This process directly relates to primary productive activities in agriculture,
|
||||||
|
which constitutes the fundamental operational level of economic production in Smith's
|
||||||
|
framework.
|
||||||
|
classified_at: '2026-02-23T10:42:36.580748'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Technology Adoption
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural Technology Adoption represents an ongoing activity or transformation where new technologies are implemented and integrated into agricultural practices over time, making it a process rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process directly relates to primary productive activities in agriculture, which constitutes the fundamental operational level of economic production in Smith's framework.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: agricultural_trade
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Agricultural trade is described as "the exchange of agricultural products
|
||||||
|
between different regions or countries" which represents an ongoing activity or
|
||||||
|
flow rather than a static entity that exists independently.
|
||||||
|
vsm_rationale: Agricultural trade constitutes a primary productive activity that moves
|
||||||
|
agricultural goods between regions, functioning as a core operational process that
|
||||||
|
enables economic specialization and resource distribution.
|
||||||
|
classified_at: '2026-02-23T10:42:42.441163'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Agricultural Trade
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Agricultural trade is described as "the exchange of agricultural products between different regions or countries" which represents an ongoing activity or flow rather than a static entity that exists independently.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
Agricultural trade constitutes a primary productive activity that moves agricultural goods between regions, functioning as a core operational process that enables economic specialization and resource distribution.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: alien_merchant_duties
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S3*
|
||||||
|
type_rationale: Alien Merchant Duties represent a socially constructed rule system
|
||||||
|
that governs how foreign merchants can operate within domestic markets, functioning
|
||||||
|
as a regulatory framework rather than a physical entity or process.
|
||||||
|
vsm_rationale: These duties operate as an audit and compliance mechanism that inspects
|
||||||
|
and controls foreign merchant activities to ensure adherence to protectionist policies,
|
||||||
|
fitting Beer's S3* function of monitoring and enforcement.
|
||||||
|
classified_at: '2026-02-23T10:42:45.901525'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Alien Merchant Duties
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3*
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Alien Merchant Duties represent a socially constructed rule system that governs how foreign merchants can operate within domestic markets, functioning as a regulatory framework rather than a physical entity or process.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
These duties operate as an audit and compliance mechanism that inspects and controls foreign merchant activities to ensure adherence to protectionist policies, fitting Beer's S3* function of monitoring and enforcement.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: ancient_system_of_political_economy
|
||||||
|
entity_type: Institution
|
||||||
|
vsm_system: S5
|
||||||
|
type_rationale: The Ancient System of Political Economy represents a socially constructed
|
||||||
|
rule system and governance structure that organized economic activity around agricultural
|
||||||
|
development as the foundation of national wealth.
|
||||||
|
vsm_rationale: This system operates at the policy level by defining the fundamental
|
||||||
|
identity and purpose of economic organization, establishing agriculture as the ultimate
|
||||||
|
authority for wealth creation before modern commercial systems emerged.
|
||||||
|
classified_at: '2026-02-23T10:42:49.015962'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Ancient System Of Political Economy
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Institution
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S5
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
The Ancient System of Political Economy represents a socially constructed rule system and governance structure that organized economic activity around agricultural development as the foundation of national wealth.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This system operates at the policy level by defining the fundamental identity and purpose of economic organization, establishing agriculture as the ultimate authority for wealth creation before modern commercial systems emerged.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
entity_slug: annual_coinage_expense_justification
|
||||||
|
entity_type: Relation
|
||||||
|
vsm_system: S3*
|
||||||
|
type_rationale: This entity represents a structural dependency between government
|
||||||
|
coinage operations and public expenditure, specifically the causal link that connects
|
||||||
|
unnecessary public costs to the lack of proper seignorage mechanisms.
|
||||||
|
vsm_rationale: This justification operates within the audit function by examining
|
||||||
|
the integrity and compliance of government coinage operations, specifically whether
|
||||||
|
public expenditure on minting serves legitimate public purposes or represents wasteful
|
||||||
|
subsidy.
|
||||||
|
classified_at: '2026-02-23T10:42:52.647161'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Annual Coinage Expense Justification
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Relation
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S3*
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
This entity represents a structural dependency between government coinage operations and public expenditure, specifically the causal link that connects unnecessary public costs to the lack of proper seignorage mechanisms.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This justification operates within the audit function by examining the integrity and compliance of government coinage operations, specifically whether public expenditure on minting serves legitimate public purposes or represents wasteful subsidy.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: annual_consumption_of_goods
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Annual consumption of goods represents a flow or activity that occurs
|
||||||
|
over time rather than something that exists independently, as it describes the ongoing
|
||||||
|
process of using up produced goods within a year.
|
||||||
|
vsm_rationale: This process represents the final stage of primary economic operations
|
||||||
|
where the goods produced through agricultural labor, manufacturing, and trade are
|
||||||
|
actually consumed by society.
|
||||||
|
classified_at: '2026-02-23T10:42:56.059406'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Annual Consumption Of Goods
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Annual consumption of goods represents a flow or activity that occurs over time rather than something that exists independently, as it describes the ongoing process of using up produced goods within a year.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process represents the final stage of primary economic operations where the goods produced through agricultural labor, manufacturing, and trade are actually consumed by society.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: annual_consumption_of_metals
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Annual consumption of metals is an ongoing activity involving the
|
||||||
|
continuous use and depletion of precious metals through wear, damage, and industrial
|
||||||
|
processes over time, making it a flow rather than a static entity.
|
||||||
|
vsm_rationale: This consumption represents primary productive and industrial activities
|
||||||
|
that physically transform and utilize precious metals as inputs in the real economy's
|
||||||
|
operations.
|
||||||
|
classified_at: '2026-02-23T10:42:59.628828'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Annual Consumption Of Metals
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Annual consumption of metals is an ongoing activity involving the continuous use and depletion of precious metals through wear, damage, and industrial processes over time, making it a flow rather than a static entity.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This consumption represents primary productive and industrial activities that physically transform and utilize precious metals as inputs in the real economy's operations.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: annual_importation_of_gold_and_silver_purposes
|
||||||
|
entity_type: Process
|
||||||
|
vsm_system: S4
|
||||||
|
type_rationale: This represents an ongoing economic activity - the flow of importing
|
||||||
|
precious metals for specific commercial purposes - rather than a static entity or
|
||||||
|
abstract principle.
|
||||||
|
vsm_rationale: This process involves analyzing and understanding the environmental
|
||||||
|
function of precious metals in facilitating foreign trade, which constitutes intelligence
|
||||||
|
gathering about how the economic system adapts to international commerce needs.
|
||||||
|
classified_at: '2026-02-23T10:43:03.286972'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Annual Importation Of Gold And Silver Purposes
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Process
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S4
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
This represents an ongoing economic activity - the flow of importing precious metals for specific commercial purposes - rather than a static entity or abstract principle.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This process involves analyzing and understanding the environmental function of precious metals in facilitating foreign trade, which constitutes intelligence gathering about how the economic system adapts to international commerce needs.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
entity_slug: annual_industry_employed_in_production
|
||||||
|
entity_type: Element
|
||||||
|
vsm_system: S1
|
||||||
|
type_rationale: Annual Industry Employed in Production represents a measurable stock
|
||||||
|
of productive capacity that exists as a persistent resource within the economic
|
||||||
|
system, rather than being an activity or process itself.
|
||||||
|
vsm_rationale: This entity represents the fundamental productive operations that create
|
||||||
|
commodities and bring them to market, which is the core function of S1 primary operations
|
||||||
|
in Beer's model.
|
||||||
|
classified_at: '2026-02-23T10:43:06.707076'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Classification: Annual Industry Employed In Production
|
||||||
|
|
||||||
|
## Entity Type
|
||||||
|
|
||||||
|
Element
|
||||||
|
|
||||||
|
## VSM System
|
||||||
|
|
||||||
|
S1
|
||||||
|
|
||||||
|
## Type Rationale
|
||||||
|
|
||||||
|
Annual Industry Employed in Production represents a measurable stock of productive capacity that exists as a persistent resource within the economic system, rather than being an activity or process itself.
|
||||||
|
|
||||||
|
## VSM Rationale
|
||||||
|
|
||||||
|
This entity represents the fundamental productive operations that create commodities and bring them to market, which is the core function of S1 primary operations in Beer's model.
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user