Content Mapping

Overview

Every vault entity type maps to a specific site section and URL pattern. This document is the registry of those mappings — the bridge between vault architecture and web architecture. The mapping tables below are extracted from the same transform-content.mjs script that builds adna.network.

Every count on this page is derived, not remembered. Re-derive before quoting: the mapping-table sizes from site/scripts/transform-content.mjs, the published totals from a fresh site/dist/. Figures below were derived 2026-09-11. A count in prose is a claim with an expiry date, and this page has already outlived one set — see Current Gaps.

Two Publishing Pathways

Content reaches the site through two distinct mechanisms:

Pathway 1: Transform Script

The transform-content.mjs script handles content from the WHAT and HOW triad legs. Eight mapping tables define source-to-output transformations:

Vault Directory	Entity Type	Site Collection	URL Pattern	Count
`what/concepts/`	concept	`content/docs/`	`/learn/concepts/{slug}`	13
`what/patterns/`	pattern	`content/docs/`	`/patterns/{slug}`	8
`what/comparisons/`	comparison	`content/docs/`	`/learn/comparisons/{slug}`	5
`what/use_cases/`	use_case	`content/docs/`	`/use-cases/{slug}`	6
`what/tutorials/`	tutorial	`content/guides/`	`/learn/tutorials/{slug}`	9
`what/docs/`	reference	`content/reference/`	`/reference/{slug}`	8
`how/publishing/`	publishing	`content/docs/`	`/how/publishing/{slug}`	3
`how/workshops/`	workshop	`content/docs/`	`/how/workshops/{slug}`	4

Each mapping entry defines: source (vault filename), slug (URL segment), title (display name), and type-specific fields (order, difficulty, time, stability, version).

Pathway 2: Direct Astro Pages

Some collections use direct .astro pages with dynamic [...slug].astro routes. These bypass the transform script and read content directly:

Vault Directory	Entity Type	URL Pattern	Count
`what/glossary/`	glossary_entry	`/glossary/{slug}`	25
`who/community/`	community	`/community/{slug}`	3

This second pathway emerged when WHO-triad content arrived that did not fit the transform script’s original WHAT-only architecture. Both pathways coexist — the transform script handles bulk content with complex transformations, while direct pages handle smaller collections with simpler needs.

The Wikilink Registry

The transform script maintains a 60-entry wikilink map that converts Obsidian [[wikilinks]] to site URLs. Every content entity gets a registered entry:

'concept_triad': { url: '/learn/concepts/triad', label: 'The Triad' },

When a vault file references [The Triad](/learn/concepts/triad), the transform rewrites it to [The Triad](/learn/concepts/triad). Unregistered wikilinks pass through unchanged — this makes missing registrations visible in site builds rather than silently breaking links.

Adding New Content Types

To publish a new vault entity type on the site:

Choose the pathway. Use the transform script for large collections needing frontmatter rewriting and wikilink resolution. Use direct Astro pages for small collections with straightforward rendering.
For transform script: Add a mapping table (source → slug → title → order), add wikilink entries, create a transformX() function following the existing pattern, and call it from the main block.
For direct pages: Create a [...slug].astro page under site/src/pages/, an index page, and add the route to the site navigation.
Register wikilinks. Any new entity needs entries in the wikilink map so other content can link to it.

Current Gaps

⛔ Corrected 2026-09-11. This section used to read: “The HOW triad leg (how/publishing/, how/workshops/) is not yet published to the site. This content — including the document you are reading — exists in the vault but has no site pathway.” Every clause of that was false when you read it. There are 15 built /how/ pages; this document is served at /how/publishing/content-mapping; and it is row 2 of the publishingMapping table in the very script this page says its tables are extracted from. The claim outlived the gap it described and nothing re-read it, because a sentence asserting that something is missing proposes no work — so nothing schedules a look. Kept rather than deleted: the failure is the most useful thing on the page.

Not everything in the vault reaches the site, and the gaps are real ones — derived 2026-09-11 by counting vault sources against built output:

Vault content	On the site	Gap
`what/patterns/` (25)	8 published	17 patterns exist only in the vault
`what/docs/` (20)	8 mapped to `/reference/`	12 unmapped
`what/glossary/` (30)	25 published	5 unmapped
`who/reviewers/` (16)	—	no route; reviewer personas are an internal review instrument
`who/adopters/` (16)	—	no route of its own; `/adopters/` redirects to `/use-cases/`

The operational HOW entities — campaigns/, missions/, sessions/, backlog/, skills/, templates/ — are deliberately unpublished. They are the vault’s working record, not its public face; the Triad publishes what a reader needs, not everything the vault holds. Likewise who/governance/ and who/coordination/.

A gap in this table is a claim like any other. If you are reading this more than a release or two after the derivation date above, re-derive it before repeating it.

Self-Reference

These mapping tables ARE the vault’s own content architecture viewed from the publishing side. The Ontology defines entity types; this document shows where each type lands on the web. The two-pathway pattern itself demonstrates the Base/Extension pattern: the original transform script is the base, and direct Astro pages are the extension added when new entity types outgrew the original design.

Vault-to-Site Pipeline — the end-to-end pipeline these mappings feed
Social Sharing — how published pages appear when shared
The Ontology — the entity type system that this mapping reflects
Base/Extension — the pattern demonstrated by the two-pathway architecture