**SoR rule:** anything a user would take with them on export lives in **markdown (and assets)**. DB holds **derived** indexes and app-only linkage (e.g. Member UUID ↔ NetKingdom subject) that is not “content.”
| Intent | Library + `mkt` CLI; no accounts/hosting | Full document platform; being **retired / split** |
| For coulomb | **Use** as dependency for structured markdown | **Avoid as runtime foundation** |
| Evidence | `markitect-tool/docs/markitect-main-scope-assessment.md`: tool is clean contract, not a trimmed copy of main; main’s infospace/spaces/DB/graphql out of tool scope | `markitect-main/docs/successor-gap-assessment.md`: main → tool + kontextual-engine + infospace-bench + filter + quarkdown |
**Decision (this exploration):**
- Treat **markitect-main as legacy reference / mine for ideas**, not as coulomb’s foundation.
- Integrate **markitect-tool** (and its contracts) for document structure operations.
- Persistence/orchestration of multi-backend wiki shape → evaluate **shard-wiki** / engine, not markitect-main `spaces/`.
---
## Decision direction: shard-wiki as backend
### What shard-wiki is
From `shard-wiki` INTENT/SCOPE:
- **Git-based markdown wiki orchestrator and federation layer**
- Joins **shards** (folder, git, native engine, future adapters) into a **union of pages**
- **Headless, API-first**; UI is a consumer concern (fits coulomb UI)
- **Does not implement** authn / identity store — **delegates to external IdP** (NetKingdom / user-engine) — matches coulomb
- Explicitly lists **“Systems such as Coulomb spaces”** as intended consumers
- Early-stage but substantial foundation (adapters, union, overlays, git coordination log, native engine shard) — not vapor intent only
### Fit to coulomb constraints
| Need | shard-wiki fit |
|------|----------------|
| Markdown as SoR | Strong — pages are wiki-shaped markdown content |
| Export / user-owned data | Strong — shards can be folder/git; take the files |
| DB as cache | Compatible — coulomb projects cards into Postgres; shard-wiki not required to be the card DB |
| NetKingdom identity | Compatible — IdP external; shard-wiki owns authz model for pages/shards |
| Avoid reimplementing wiki federation | Strong |
| Risk: “too much structure” | Real — namespaces, overlays, federation, capability profiles, multi-shard resolution are more than a single-tenant space CRUD MVP |
### “Too much structure?”
shard-wiki’s structure is **mechanism** (resolution, overlays, provenance, multi-shard), not a fixed **product ontology** (it refuses a universal knowledge ontology). Risk for coulomb is **operational and API surface**:
- If coulomb calls the full federation graph on day one, stage-1 product work drowns in coordination concepts.
- If coulomb uses a **thin slice**: one InformationSpace per tenant (or per product instance), **one primary shard** (folder or git or native engine) for space pages, overlays only when needed — structure stays **under the hood**.
**Evaluation stance:**
| Approach | When |
|----------|------|
| **A. shard-wiki as content plane** | Prefer if we want federation (personal + space shards, export shards, git sync) and headless page ops soon |
| **B. coulomb thin page store + markitect-tool** | Prefer if stage-1 ships faster with a single folder/git layout; adopt shard-wiki when multi-shard or federation is real demand |
| **C. kontextual-engine** | Broader knowledge ops; evaluate if page-only wiki is too narrow long-term — heavier product fit analysis |
**Preferred exploration order:** prove stage-1 page ops against a **minimal shard-wiki deployment** (or adapter conformance test) **in parallel** with a **simple folder/git adapter design**. Choose A if integration cost is acceptable and API stays stable; else B with a migration path **to** shard-wiki (adapter contract is designed for that).
Do **not** pick markitect-main as the store.
---
## NetKingdom / Railiance (unchanged ownership)
| Concern | Owner |
|---------|--------|
| User accounts, login, MFA, groups/roles claims | NetKingdom |
| Application Member link (issuer, subject) | coulomb (JIT) |
| Tenant model | instance-per-client + `tenant_id` (DR-1 C); platform claims when ready |
