# MarkiTect Main Scope Assessment

Date: 2026-05-03

## Purpose

This assessment compares `/home/worsch/markitect-main` against the
`infospace-bench` intent, PRD, and FRS. It identifies which ideas should be
migrated, reimplemented, referenced, or deliberately left behind.

## Summary

`markitect-main` already contains substantial infospace work, but it is bundled
with responsibilities that this repo explicitly excludes: markdown parsing,
schema tooling, rendering, asset management, GraphQL experiments, prompt
runtime infrastructure, and broad platform behavior.

`infospace-bench` should therefore become a focused successor for the
application-layer infospace lifecycle. The right move is selective
reimplementation and migration of concepts, examples, tests, and documentation,
not a package copy.

## Source Areas Reviewed

| MarkiTect area | Assessment | Successor action |
| --- | --- | --- |
| `markitect/infospace/` | Closest match. Contains entity metadata, config, evaluation, collection checks, history, composition, relation parsing, graph export, and CLI glue. | Reimplement as the first functional baseline, adapting boundaries to lower-layer deps. |
| `examples/infospace-with-history/` | Strong reference experiment with `infospace.yaml`, source corpus, pipeline stages, viability thresholds, outputs, and metrics methodology. | Migrate as a reference pilot after pruning generated bulk and documenting provenance. |
| `docs/infospace-primitives.md` | Useful conceptual reference for topic, discipline, entity, evaluation, viability, checks, history, and composition. | Rewrite into this repo's docs with updated architecture terms. |
| `markitect/prompts/` | Provides generation workflow, dependency resolution, quality gates, traceability, and batch execution. | Reimplement only workflow-facing contracts; runtime/provider mechanics belong outside or behind adapters. |
| `markitect/analysis/graph.py` and relationship exports | Relevant for inspection and visualization. | Keep graph/relationship inspection as an application feature; rely on lower layers for reusable primitives where possible. |
| `markitect/schema/` and legacy schema modules | Useful as input constraints, but lower-level schema tooling is out of scope. | Reference or depend on schema tooling; do not copy wholesale. |
| `markitect/packaging/transclusion/` and `markitect/spaces/transclusion/` | Useful conceptually for composed artifacts, but implementation is syntax/tooling heavy. | Treat as dependency or later integration point, not first migration. |
| `markitect/assets/`, rendering plugins, static assets | Mostly outside current PRD/FRS except exported artifacts. | Leave behind unless a concrete infospace export needs assets. |
| GraphQL/server experiments | Platform/API layer not validated for this repo. | Defer. Start with CLI/service contracts only after the domain model is stable. |

## In-Scope Concepts To Carry Forward

- `infospace.yaml` as a declarative project artifact
- Topic, discipline binding, entity, relation, evaluation, and viability
- Entity parsing into structured metadata
- Collection checks: redundancy, coverage, coherence, consistency, granularity
- Metrics history and snapshot diffs
- Viability thresholds as explicit acceptance criteria
- Relationship graph export and inspection
- Reference corpus workflow: sources -> analyses -> entities -> mappings ->
  evaluations -> reports
- Pipeline definitions that are inspectable and reproducible

## Reimplementation Boundaries

The successor should reimplement interfaces around these concepts, but with
cleaner responsibility boundaries:

- Markdown parsing should come from `markitect-tool` or a thin adapter.
- Persistence and long-running workflow orchestration should come from
  `kontextual-engine`.
- LLM calls should use `llm-connect` or an equivalent provider adapter.
- This repo should own concrete configuration, project layout, reports,
  fixtures, workflow definitions, and application-level glue.

## Initial Architecture Recommendation

Start with a file-backed baseline before adding a service:

```text
infospaces/<slug>/infospace.yaml
infospaces/<slug>/artifacts/
infospaces/<slug>/output/
workflows/
reports/
docs/
```

Then add a small CLI around the FRS lifecycle:

- `create`
- `load` / `inspect`
- `add-artifact`
- `evaluate`
- `check`
- `export`

Only introduce a service/API when there is a concrete need for long-running
state, external consumers, or integration with `kontextual-engine`.

## Migration Priority

1. Documentation and repo shape
2. Infospace config and artifact model
3. Evaluation output and metrics history
4. Collection checks and relationship inspection
5. Reference infospace pilot
6. Workflow execution and AI-assisted generation
7. Service/API layer

## Non-Migration List

Do not migrate these directly into `infospace-bench`:

- General markdown parser/serializer modules
- Schema generator/validator libraries as reusable tooling
- Asset management subsystem
- Rendering/plugin infrastructure
- GraphQL platform experiments
- Database and orchestration infrastructure
- Legacy compatibility layers

## Open Questions

- Should `infospace-bench` depend directly on local sibling repos during early
  development, or use published/package boundaries from the start?
- Which reference infospace should be the first maintained pilot: the existing
  Wealth of Nations/VSM experiment, or a smaller purpose-built corpus?
- Should State Hub track each infospace as its own workstream once the repo
  model exists?