# 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

```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.