infospace-bench/docs/orthogonal-successor-roadmap.md

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

Supporting architecture artifacts:

• docs/legacy-infospace-feature-inventory.md
• docs/successor-boundary-interface-map.md
• docs/replacement-acceptance-matrix.md

Sequencing

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.