Reestablishing intent based goals and workplans

docs/orthogonal-successor-roadmap.md

@@ -0,0 +1,93 @@
+# Orthogonal Successor Roadmap
+
+Date: 2026-05-14
+
+## Purpose
+
+This roadmap explains how `infospace-bench`, `markitect-tool`, and
+`kontextual-engine` should together replace the relevant functionality of the
+original `markitect-project` without recreating a monolith.
+
+## Orthogonal Roles
+
+| Repository | Layer | Owns | Must not own |
+| --- | --- | --- | --- |
+| `markitect-tool` | Syntax | Markdown parsing, document structure, contracts, validation, references, transformations, local query/cache primitives, CLI/library tooling | Concrete knowledge-space projects, durable operational state, domain workflows |
+| `kontextual-engine` | System | Persistent asset identity, ingestion, metadata, relationships, retrieval, governed transformation, workflow execution, APIs, permissions, auditability | Markdown-specific syntax rules, one domain application, final knowledge-space methodology |
+| `infospace-bench` | Application | Concrete infospaces, artifact manifests, evaluation methodology, inspection reports, reference experiments, applied workflows, migration pilots | Low-level Markdown tooling, general runtime/orchestration platform, reusable engine primitives |
+
+## Replacement Principle
+
+The old `markitect-project` combined syntax, runtime, application, examples,
+and experiments in one repo. The successor architecture should preserve the
+useful behaviors by relocating them to the correct layer:
+
+- Markdown document mechanics move to `markitect-tool`.
+- Persistence, retrieval, orchestration, governance, and agent-safe operations
+  move to `kontextual-engine`.
+- Infospace definitions, experiments, quality methodology, concrete pilots,
+  and applied inspection workflows live in `infospace-bench`.
+
+`infospace-bench` should therefore replace the old infospace feature surface as
+an **application composition** of the two lower layers, not as a direct code
+copy.
+
+## Legacy Feature Placement
+
+| Old `markitect-project` feature | New home | Notes |
+| --- | --- | --- |
+| Markdown AST parsing and section extraction | `markitect-tool` | `infospace-bench` consumes via adapter. |
+| Entity/relation Markdown shape validation | `markitect-tool` + `infospace-bench` | Generic contract validation in tool; infospace-specific contract selection in bench. |
+| Infospace config and project layout | `infospace-bench` | Concrete application artifact. |
+| Entity and relation domain models | `infospace-bench` | Application-level knowledge semantics. |
+| Collection checks and viability thresholds | `infospace-bench` | Methodology belongs with applied infospaces. |
+| Metrics history and evaluation reports | `infospace-bench` initially; `kontextual-engine` later for durable storage | File-backed first, engine-backed when needed. |
+| Source processing pipelines | `infospace-bench` definitions; `markitect-tool` transforms; `kontextual-engine` orchestration | Keep workflow intent separate from runtime. |
+| LLM-assisted evaluation/generation | `infospace-bench` workflow contracts; provider abstraction outside or lower layer | No vendor lock-in. |
+| Asset identity, provenance, retrieval, workflow runs | `kontextual-engine` | `infospace-bench` should integrate, not reimplement. |
+| Reference experiments such as Wealth of Nations/VSM | `infospace-bench` | Concrete pilot and acceptance corpus. |
+
+## Workplan Set
+
+The following `infospace-bench` workplans establish the path:
+
+1. `IB-WP-0005` — Orthogonal successor architecture and feature map
+2. `IB-WP-0006` — `markitect-tool` adapter and Markdown artifact validation
+3. `IB-WP-0007` — Entity and relation model migration
+4. `IB-WP-0008` — Evaluation history, metrics, and viability parity
+5. `IB-WP-0009` — Applied workflow and generation pipeline
+6. `IB-WP-0010` — `kontextual-engine` integration boundary
+7. `IB-WP-0011` — Pruned legacy reference pilot migration
+8. `IB-WP-0012` — Replacement readiness and CLI parity gate
+
+## Sequencing
+
+```text
+IB-WP-0005
+  -> IB-WP-0006
+      -> IB-WP-0007
+          -> IB-WP-0008
+              -> IB-WP-0009
+                  -> IB-WP-0010
+                      -> IB-WP-0011
+                          -> IB-WP-0012
+```
+
+The sequence is intentionally conservative: first prove boundaries, then add
+syntax-layer integration, then migrate application semantics, then introduce
+runtime/engine integration and final replacement gates.
+
+## Success Criteria
+
+The successor split is working when:
+
+- `infospace-bench` can run meaningful infospaces without internal Markdown
+  parser code.
+- `infospace-bench` can optionally persist and operate infospaces through
+  `kontextual-engine` without becoming an engine itself.
+- A pruned legacy MarkiTect infospace can be migrated and evaluated with
+  traceable outputs.
+- Users can see which old `markitect-project` infospace commands are replaced,
+  reframed, delegated, or intentionally retired.
+- The three repos remain independently understandable from their own
+  `INTENT.md` files.