Skip to Content

Glossary

One crisp definition per term. Where a term has a fuller treatment elsewhere, the definition links to it. Terms are alphabetised.


AEO / citability gate — the quality check that scores a drafted page on how likely AI answer engines are to cite it (AEO = Answer Engine Optimisation). The engine-owned review-gate skill knows how to score; the numbers (weighted dimensions, thresholds, answer-block length) are tuned in gtmesh.config.yaml under aeo:. A page passes only when every dimension clears its bar, the weighted overall clears overall_threshold, and there are no blockers.

apply — the command that makes reality (the registry plus the page files) match desired state. Idempotent and Terraform-style: it previews what it will do and prompts to confirm (--yes skips). It only acts when there’s a difference, so it’s always safe to re-run. apply, seal, and the lifecycle commands are the only writers of the registry.

article-writer — the repo-local skill that fills page bodies (and the editorial meta fields). The one and only step where a model runs. It reads a page’s _brief, schema stubs, templates, foundation and strategy; fills the content; runs the humanizer and gtmesh validate; then invokes the review-gate. It never touches the slug, the mesh links, or the registry.

the bag — the data/raw/ directory: immutable, timestamped keyword/search exports written by extract. plan reads the frozen bag and never re-fetches, so a plan is reproducible from committed data.

built hashes — the three provenance hashes seal stamps onto a built row: built_content_hash, built_projection_hash, and built_schema_hash. They record what a page was built from, which is what makes later diffs precise (the engine can tell exactly what changed). See also content_hash / projection_hash.

catalogue — a reconcile action: a brand-new identity is recorded in the registry with no page created yet, because it isn’t promoted to an actionable status. (Contrast create.)

catalogue loop vs production loop — the two rhythms GoToMesh runs in. The catalogue loop (extract → plan → apply) is cheap and automatic: it keeps the map of everything that could exist in sync, and is safe to schedule. The production loop (promote → apply → write → seal → publish) is deliberate: it decides which catalogued pages to actually build, then builds, reviews, and ships them. promote is the gate between the two.

cluster — a grouping axis a page belongs to. There are two axes, declared under taxonomy.clusters: category (e.g. crm, messaging, payments — what the page is about) and topic (e.g. education, comparison, use-case — how it’s framed). Clusters drive sibling links. See the mental models.

content-types package — the workspace TypeScript package gtmesh types emits (default packages/content-types/) for an SSG or other consumer to compile against. It carries generated per-type page interfaces plus a registry reader and page loaders. gtmesh types --check is the CI gate against drift.

content_hash / projection_hash — the two hashes that determine what changes when an input moves. content_hash covers the body inputs (primary and secondary keywords, intent, tier, section, template, content-determining columns); changing them rewrites the body. projection_hash covers the render projection (slug, mesh links, in-projection columns); changing them only re-derives the deterministic meta. By construction content_hash ⊆ projection_hash, so a body change implies a projection change and the higher-cost action wins. The built_* variants are the built hashes stamped at seal.

create — a reconcile action: a brand-new identity that is already promoted to an actionable status (queued/writing/ needs_update) gets its page scaffolded and moves to writing. (Contrast catalogue.)

desired state — what the registry should be, computed by plan from your inputs (config, reference tables, seeds, the bag). apply makes actual state match it. This is the central idea: the registry is the desired state, the plan is the diff against it, and Git is the audit log. See the mental models.

discovery — the optional, tailored bootstrap (run via gtmesh discover in an empty dir). It installs the discovery skill and prints a prompt; the skill interviews you and writes a gtmesh-discovery.yaml (mesh shape + clustered starter seeds) that gtmesh init --from-discovery scaffolds from. It runs outside the deterministic loop. See the discovery contract.

discriminator — one of the composite identity keys: the field that distinguishes two pages that would otherwise collide on the same parent_topic and page_type. It keeps each identity unique.

entities.csv — the reference table (reference/entities.csv, keyed by slug) listing the project’s entities — brands, products, categories — with their class and other columns. Used in classification and to group siblings (e.g. brand hubs sibling with same-class brands).

entity / entities — a real-world thing the content is about (a brand, a product, a category) rather than a keyword string. Semantic SEO optimises for entities, not exact-match strings; GoToMesh resolves a keyword to its entity via entities.csv, and the highest-priority class wins when several match.

extract — the command that pulls keyword/search signals into the bag (data/raw/). A cluster pull runs two pulls (matching-terms and questions) and expands a seed into many related keywords; --source seeds refreshes a curated term list’s metrics without expansion. Exports are immutable and timestamped.

freeze (slug) — see slug anchor (head) & freeze.

funnel_target — for a page whose SERP layer is content, the landing it funnels up into (named by slug or parent_topic). It’s the edge from an informational page to the commercial page it supports. Set as a frozen discovery decision alongside funnel; inert on a non-commercial mesh.

GoToMesh — the product: a deterministic, self-refreshing programmatic-content mesh engine. The name is a play on go-to-market — it builds your go-to-market as a content mesh. gtmesh is its command-line tool.

harvest — the engine-owned skill that figures out what pages should fill an entity class (a glossary especially) from demand signals: it brainstorms candidates per taxonomy family, ranks them against a demand corpus, validates demand via Ahrefs, scores the cut, writes a curated term list to seeds/<class>.csv (terms + provenance, never metrics), then stops for human review. Configured under discovery: in gtmesh.config.yaml.

hub / sub-hub / spoke — the authority topology of a topic cluster. A hub is the authoritative center of a subject (a Tier-A conversion page); spokes are the supporting leaf pages that link up to it; a sub-hub is an intermediate hub beneath the apex. Links between them are derived from the registry, not hand-placed.

humanizer — the skill that strips AI-writing tells from a draft and pulls it toward the project’s house voice (foundation/voice.md). The detection patterns are generic and engine-owned; the target voice is yours. The article-writer runs it before the review-gate.

identity / identity_keys — a page’s stable identity is a composite key: the fields in identity_keys (default parent_topic, page_type, discriminator — and market joins automatically once there’s more than one market). Two rows with the same identity are the same page. Identity is what the registry diff keys on. See the mental models.

image-director — the skill that generates and places the images a page has briefed. It reads the page’s art-direction briefs plus foundation/art-direction.md and the images: config, generates via the image MCP, writes the asset files into the page bundle, and adds asset: to each slot. Invoked explicitly, separate from writing.

intent — the single search intent a page serves (e.g. transactional, commercial, branded, informational). Declared in taxonomy.intents in priority order; classify picks the first present on a keyword. Semantic SEO’s rule is one intent per page, which GoToMesh enforces by construction.

kind (site type) — the project’s authority topology, set once in gtmesh.config.yaml. One of non_commercial (content hubs discovered from demand), commercial_catalog (many product/category pages plus an order action), or commercial_pages (a few core landings that content funnels up into). Everything about tiering follows from it. See the mental models.

mesh — the whole interlinked set of pages plus the derived link graph between them. The committed registry is the mesh’s source of truth; links, tiers, redirects and breadcrumbs are all derived from it and re-derived on every change.

needs_update — a status: a built page whose body inputs changed and whose revision hasn’t shipped yet (the old body keeps serving until it does). Also the status a shipped page re-enters after assets are placed (gtmesh amend).

noop — a reconcile action: nothing changed for this identity, so the engine does nothing.

parent_topic — one of the identity keys, and the legacy slug stem. With slug anchoring set to head, a page’s URL is named after its head keyword rather than parent_topic, but identity still keys off parent_topic. A change to it is a rename.

plan — the command that recomputes desired state and shows the diff against the committed registry. Read-only — it prints the diff and writes a derived, git-ignored .gtmesh/plan.json, but changes nothing. apply computes the same diff itself, so plan is an optional preview you run whenever you want a look.

promote — the intent-based gate that chooses which catalogued pages to build. It writes only status (e.g. plannedqueued), builds nothing, and is reversible (demote). It selects rows by registry fields (section, cluster, tier, page-type, slug prefix, status) or by a graph walk (--under <hub>), and applies by default (--dry-run previews). It’s the gate between the catalogue and production loops.

prune — a reconcile action, human-gated: when an identity’s input disappears, its row is carried forward (not silently dropped) and its bundle folder lingers until gtmesh apply --prune removes both together.

pulls (matching-terms, questions) — the two-pull pattern a cluster extract runs against Ahrefs: matching-terms (the broad keyword expansion) and questions. Both land in the bag.

reconcile actions — the one-action-per-identity verbs plan emits by diffing desired state against the committed registry. They are: noop (nothing changed), recompute (an unbuilt row’s inputs changed), rewrite (a built page’s body inputs changed — pulls the writer back in), restamp (a built page’s render projection changed — engine re-derives meta, no writer), relink (the restamp reason when a mesh edge moved), redirect (a slug changed — human-gated, moves the bundle and appends the ledger), prune (an identity’s input vanished — human-gated), catalogue (record a new identity, no page), and create (scaffold a new, already-promoted identity). Who acts varies: the engine handles recompute/ restamp/relink/catalogue/create; the writer handles rewrite; redirect and prune are human-gated.

redirect ledger (registry/redirects.csv) — the durable, cumulative record of slug changes (old slug → current). When a slug changes, apply moves the bundle and appends the hop here; the ledger collapses chains (A→B then B→C ⇒ A→C) and never truncates, so old URLs resolve forever and the SSG emits 301s.

registryregistry/pages.csv: the committed source of truth for every page that could exist and what state each is in. It’s the diffable artifact — the state file. Never hand-edited; apply, seal and the lifecycle commands are its only writers. See the mental models.

rename — moving a page’s URL via an explicit group-edit (or a parent_topic change). A committed slug is frozen, so only a rename moves it — firing a 301 and a bundle move, and appending to the redirect ledger.

review-gate — the independent, blocking quality reviewer the article-writer invokes as its final pre-seal step. It scores AEO/citability and enforces the house voice in one pass, returning a PASS/FAIL report. On failure the page stays in writing with notes; on pass it returns control to the writer. It never calls gtmesh seal.

role — the authority role a page plays — chiefly hub vs spoke. Computed from the signals and seed-pages, and used by the link rules (a hub links differently from a spoke). See the mental models.

seed / seeds/<class>.csv — a seed is a starting keyword or term that feeds the pipeline. seeds/<class>.csv is a curated, human-reviewed term list for an entity class (written by harvest) — terms plus provenance only, never metrics (Vol/KD live in the bag and refresh on cadence). A curated term is seed-authoritative: plan keys its identity and routing off the curated term and the seed’s section/page_type. Distinct from a seed-page.

seed-page (reference/seed-pages.csv) — a source-less page you declare by hand — typically an apex or pillar hub that no keyword pull would mint on its own. Distinct from a seed (a keyword/term). See the mental models.

SERP layer (layer: commercial/content/mixed) — a classification of a keyword’s search results by what’s actually ranking (derived from a SERP teardown). It separates the money layer from the content layer so a commercial page ships by business priority rather than volume. See also funnel_target.

signals.csv — the reference table (reference/signals.csv, keyed by signal) that maps keyword signals to role/tier — the input that tunes how keywords are classified into hubs, feeders and spokes.

slug — a page’s URL path. The only deterministic field in a page’s meta (apply-owned); the editorial meta fields are writer-authored. Don’t hand-edit the slug — fix the inputs and re-plan. See the mental models.

slug anchor (head) & freeze — with identity.anchor: head, a page’s URL is named after its head keyword (the volume-ranked primary), not a divergent parent_topic. The head can flip on re-extract, so a committed slug is frozen (sticky registry state): only an explicit rename group-edit moves it (firing a 301 and bundle-move). Identity stays parent_topic either way.

status lifecycle — the states a row’s status moves through: planned (catalogued, not authorised) → backlogqueued (promoted to build) → writing (page scaffolded, awaiting a body) → review (sealed) → published (live), plus needs_update (a built page whose inputs changed). Status moves are deliberate human edits (via promote/demote/seal/ publish), separate from the input-driven reconcile actions.

tier (A/B/D) — the authority tier a page sits in, in the default scaffold: A = conversion (the entity hubs / money pages, where authority converges), B = feeder (comparison and use-case pages that funnel to A), D = spoke (glossary/educational leaf pages). The authority flow runs D → B → A. See the mental models.

Last updated on