| Term | What it is | Convention + collision-avoidance note |
|---|---|---|
| The Master GTM | The parent program / doctrine for Webgold Designs marketing. | Singular noun. Not "the Master GTM cascade" (that's loose). Not "the cascade" (ambiguous). |
| The Reef | The metaphor describing what the Master GTM is operating-system-wise. | Used in Spine §1 and the Reef Briefing. Internal language; surfaces in public copy as subtext, not headline. |
| Master GTM artefact set | The nine HTML/document deliverables. | Spine · Phase Architecture · Channel Matrix · Harmony Calendar · Gate & Tempo · Filter Card · Reef Briefing · Cascade Execution Guide · Alignment Layer. |
| Cascade Execution Guide | The build register / project-management doc. | Where build state, decisions, and the master task register live. Working document, not a public deliverable. This is "the document for completing the project." |
| Phase | A Master GTM build phase. | Phase 0 through Phase 8. Cascading build sequence. Phases ladder up to live. |
| Cycle | A recurring operational cycle on the live system. | e.g. Cycle 5 = deploy v89 work. Cycles run after phase work, keep the live system alive. |
| Service GTM | Per-service-line marketing plan, date-bounded. | Was "Sub-GTM" in earlier cascade docs; renamed for Content Command parity (DEC-MGTM-NEW-01). |
| Buyer Personas | Pipeline targets — who buys. | Sam, Grace, Edwin, Garvin, Maya. CMIF-canonical (DEC-006). Use names in prose; persona FK in schemas. |
| Content Audience Profiles (CAPs) | Editorial audiences — who consumes Market Education Content. Not pipeline targets. | C1 Local Digital Consumer · C2 Diaspora Buyer · C3 Pre-Store Entrepreneur · C4 Social Commerce Seller. CMIF-canonical. Use names in prose; cap_id in schemas. Never write CAP-01 / CAP-02 — adds a C-prefix collision with Nucleus CON-XXX blocks. |
| Pillars | Content territories. | P1 The DX Architect · P2 Regional Commerce & Trust · P3 Practical Intelligence · P4 The Sustain Standard · P5 Caribbean Market Intelligence. Content Command-canonical, adopted into Master GTM (DEC-MGTM-NEW-03). |
| Positions | Marketing postures. | Position 1 Named Expert · 2 Caribbean Opinion · 3 Attributed Outcomes · 4 Owned Audience. Master GTM-canonical. A motion has one Pillar, strengthens 1+ Positions. |
| Tracks (T1 / T2) | Direct GTM marketing (T1) vs thematic authority (T2). | Content Command convention. Note: T1 / T2 shapes resemble T-MGTM-XXX task IDs — schema context disambiguates, but be careful in speech. |
| Code prefixes — map | For schema work, scan for collisions. | T-MGTM-XXX tasks · DEC-MGTM-XXX Master GTM decisions · DEC-XXX CMIF decisions · DT-XX decision trail · CON-XXX Nucleus content blocks · INFRA-XXX Nucleus infrastructure blocks · C1-C4 CAPs · P1-P5 Pillars · T1/T2 Tracks. |
In prose, name the thing fully (Local Digital Consumer, Edwin, Pillar 1 The DX Architect). Reserve coded forms (C1, P1, T1) for schemas, Airtable fields, and tight reference notation. Never invent new prefixes — if a code shape isn't in the table above, it doesn't exist.
The Master GTM and Content Command are not parent and child. They are peer artefacts that grew up alongside each other and now connect through a defined interface. The Master GTM's role is doctrinal — it sets the rules going in and tests the output coming out. Content Command's role is operational — it takes a Service GTM, breaks it into sprints, plans content across two tracks, generates drafts, and queues motions to ship.
Tells the engine what to make
Spine principles, four claims, four positions, banned vocabulary, channel hierarchy, position-channel activation rules, AIDAR taxonomy, five Pillars taxonomy, CMIF personas. The brief Content Command works to.
Plans content and drafts copy + structure
Service GTMs uploaded, sprints planned, T1 (direct) / T2 (thematic) split managed, Pillar + AIDAR + buyer persona + CAP assigned per item, Gemini-assisted drafting of structured copy, calendar scheduling, reactive Caribbean news triaged. This is where the motion is shaped — but not where the final asset is built.
Turns drafts into postable assets
Final-asset production lives in existing Nucleus blocks downstream of Content Command — CON-003 Core Visuals (images, graphics, templates), CON-004 Video Shorts (vertical video), CON-005 Lead Magnet (guides, toolkits, templates), and CON-006 Social Distribution (automated posting + platform formatting). They consume Content Command's structured drafts and produce final shareable assets. Out of scope for the Master GTM ↔ Content Command contract specifically, but referenced here so the chain is visible.
Approves what ships
Filter Card v1.x runs as the canonical gate before a motion ships. The exact stage at which the Filter runs — at Content Command draft stage (preventive — kills bad copy before downstream production) vs. at final-asset stage post-CON-003/004/005/006 (gate — final check on assembled motion) — is an open architectural question. Filter Card's nine tests can be evaluated on copy + plan alone, so either timing is technically defensible. The decision affects where the FILTER_PASSES log entry is written and how rework loops are sequenced. Resolved through cross-team confirmation; flagged in §6 Decision Register.
Content Command keeps its operational autonomy on planning + drafting. The downstream Nucleus blocks keep theirs on final-asset production. Master GTM keeps its doctrinal authority across both. Each layer can evolve internally without breaking the others, as long as the interface contracts hold.
Doctrine + validation
- The Spine (11 sections — Reef premise, four claims, four positions, demand-architecture, content portfolio mix, channel hierarchy, authorship, proof factory, kill list, the economy)
- The Filter Card — eight tests every motion passes (now nine with v1.1)
- The banned vocabulary list (canonical source)
- Channel Matrix — position × channel activation rules
- Phase Architecture — sprint binding to WG-25
- Gate & Tempo Protocol — weekly Tempo Gate, quarterly Posture Gate
- Service GTM authoring (via the service-gtm-builder skill)
- The Reef Briefing — single-source explainer for the team
Operational planning + content generation
- Service GTM ingestion (docx/txt/md upload + Gemini parse)
- Sprint planning surface (two-track view, T1/T2)
- Content engine (topic + pillar + AIDAR + persona → Gemini draft)
- Stockpile + roadmap views
- Calendar (working surface; syncs to Airtable Harmony Calendar)
- Reactive feed triage — Caribbean RSS news → Track 2 candidate flow
- Status pipeline: Idea → Brief Approved → In Development → Ready
- Health dashboard + export
Downstream — Master GTM feeds Content Command
Spine principles + the load-bearing sentence
The four claims, the four positions, build-as-attraction, and "Webgold sells the right to think clearly about your digital future from inside the Caribbean context — with proof, with continuity, and without translation tax." Content Command's content engine is briefed with these and produces nothing that contradicts them.
Filter Card structured sidecar
Filter Card v1.2 emits a structured sidecar (filter-card.json) — eight-plus tests as queryable rules and the banned vocabulary list as an array. Content Command's content engine queries this sidecar at draft time so it never generates content the cascade gate would reject.
Channel Matrix + AIDAR mapping
Position × Channel activation rules, augmented with AIDAR stage. Content Command consults this when assigning a content item to a channel — confirms the channel actually activates the position at the AIDAR stage of the piece.
Service GTM document
Authored by the Master GTM (via the service-gtm-builder skill), uploaded into Content Command. Date-bounded plan with track1Priorities[] and track2Themes[] arrays plus an embedded sprint structure. The boundary object — see §4.
Upstream — Content Command writes back to Master GTM
Scheduled motions → Harmony Calendar (Airtable)
Every content item that reaches Scheduled status writes a row to HARMONY_CALENDAR in Airtable, tagged with track (T1/T2), pillar (P1–P5), AIDAR stage, persona FK, and the parent Service GTM FK. The Master GTM Harmony Calendar reads this to populate its live view.
Filter pass results → FILTER_PASSES (Airtable)
Every Filter pass — pass / fail / revise — writes a row to FILTER_PASSES with the test results, banned terms found, missing elements, and source artefact. Audit trail.
Reactive feed verdicts → motion records
When a Caribbean news item is assessed ACT NOW and added to Track 2, it spawns a motion in Harmony Calendar with the source URL, source date, and a reactive_origin = true flag. Allows post-hoc analysis of what proportion of motions are reactive vs planned.
Sprint metadata → SPRINTS (Airtable)
Sprint label, dates, focal service, status. Lets the Master GTM Phase Architecture see which sprints are active across which Service GTMs without polling Content Command.
Shared — both systems read and write
Airtable HARMONY_CALENDAR — ground truth
Per cascade rule: Airtable is ground truth, surfaces are caches. Content Command's localStorage is a working cache; Airtable is the canonical record. On every Content Command launch and silent refresh, Airtable data overrides local state for fields like status, scheduled_date, and filter_outcome.
Service GTM document store
Service GTMs author once, consumed by Content Command per cycle. Stored in the project folder under Project Packages/Service GTMs/ with versioned filenames. Content Command imports the latest; Master GTM authors the next.
Service GTM document
Date-bounded plan for one service line (Support, Commerce, Identity, etc.). Carries Track 1 priorities (direct GTM marketing — only fired when this Service GTM is active) and Track 2 themes (thematic authority — focuses but doesn't replace the General GTM's permanent themes). Ingested by Content Command on upload.
Filter Card structured sidecar — filter-card.json
Filter Card v1.2 emits this alongside the human-readable HTML. Content Command's content engine queries it at draft time so the tool itself enforces the cascade gate before content even reaches the Filter pass surface. Reduces failed-Filter retry cycles to near-zero.
Harmony Calendar — Airtable HARMONY_CALENDAR table
The single ground truth for what is in flight, what has shipped, and what was killed. Both systems read and write here. Content Command schedules motions; Master GTM Harmony Calendar surface visualises them; Gate Register cross-references them on ship.
| Concept | Master GTM term | Content Command term | Reconciliation |
|---|---|---|---|
| Service-level marketing plan | Sub-GTM | Service GTM | Service GTM (cascade adopts) |
| Always-on doctrine | Spine + Filter Card | General GTM | Both — General GTM in Content Command points to Spine as source |
| Content territory | (implicit in §6) | 5 Pillars (P1–P5) | 5 Pillars adopted as canonical taxonomy |
| Marketing posture | 4 Positions | (implicit) | 4 Positions remain canonical posture taxonomy |
| Audience journey | (none) | AIDAR (5 stages) | AIDAR adopted into cascade |
| Buyer personas (pipeline targets) | CMIF — DEC-006 | Edwin, Grace, Garvin, Sam, Maya | Same — already aligned |
| Content Audience Profiles (consumption — Market Education Content, not pipeline) | CMIF — already canonical | References C3, C4 in P2 Pillar audiences | CMIF canonical (C1–C4). Content Command needs all four exposed in content engine, not only C3/C4. |
| Calendar of motions | Harmony Calendar (Airtable) | Calendar (localStorage → Airtable) | Airtable canonical; Content Command syncs |
| Quality gate | Filter Card v1.x (HTML + sidecar) | Built-in standards | Filter Card canonical; sidecar shared |
| Banned vocabulary | Filter Card list (v1.2) | Built-in list | Filter Card canonical; sidecar shared |
| Sprint metadata | (loose — by phase) | GTMSprint object | GTMSprint adopted into Airtable schema |
| Reactive content | (none) | RSS-based reactive feed | Adopted as new motion class in Harmony Calendar |
| Direct vs indirect content | (implicit) | T1 (direct) / T2 (thematic) | Adopted as Spine §6 structural cut; ratio target ~30/70 |
| Methodology framing | "doctrine first, tactics after" | "Diagnose → Design → Deliver → Sustain" | Both stay; Spine references Diagnose→Sustain as service methodology |
| Brand colours | Notion brand system (canonical) | T1 #E8593C, T2 #1B8C7A | Notion source of truth; Content Command realigns to Notion-canonical hex values |
| DEC ID | Question | Status | Resolution |
|---|---|---|---|
| DEC-MGTM-NEW-01 | Service GTM vs Sub-GTM — which name wins? | RESOLVED | Service GTM (cascade adopts Content Command convention). |
| DEC-MGTM-NEW-02 | Content Command's T1 orange #E8593C vs Webgold brand orange — which holds? | RESOLVED | Notion brand system is canonical source for all brand colours. Content Command realigns hex values to Notion-canonical. |
| DEC-MGTM-NEW-03 | Pillars and Positions coexist orthogonally? | RESOLVED | Confirmed. A motion has one Pillar (territory) and strengthens one or more Positions (posture). |
| DEC-MGTM-NEW-04 | Adopt AIDAR as content attribute across the cascade? | RESOLVED | Confirmed. AIDAR adopted into Channel Matrix dimension and Harmony Calendar schema. |
| DEC-MGTM-NEW-05 | CMIF Personas vs Content Command personas (Edwin/Grace/Garvin/Sam/Maya)? | RESOLVED | No conflict. Edwin/Grace/Garvin/Sam/Maya ARE the CMIF personas (per DEC-006). Already aligned. |
| DEC-MGTM-NEW-06 | Filter Card v1.2 adopts Content Command's two extra banned items? | RESOLVED | Confirmed. "In today's digital landscape" + "results without metric+timeframe+context" added to Filter Card v1.2. |
| DEC-MGTM-NEW-07 | Content Command relationship to Nucleus CON-002 → CON-006? | RESOLVED | Content Command implements CON-002 Editorial Calendar specifically — the orchestration pipeline. CON-003 Core Visuals, CON-004 Video Shorts, CON-005 Lead Magnet, and CON-006 Social Distribution remain separate Nucleus production blocks downstream of Content Command. (Corrected from earlier reading that suggested Content Command collapsed all five blocks.) |
| DEC-MGTM-NEW-08 | Source of truth — Airtable or Content Command localStorage? | RESOLVED | Airtable is ground truth (per cascade rule). Content Command localStorage is a working cache. Gem builds the sync layer that makes Content Command write through to Airtable. |
| DEC-MGTM-NEW-09 | Content Audience Profiles canonical home + schema integration? | RESOLVED | CMIF is canonical for CAPs (C1–C4 already exist in CMIF, lines 1090–1219). Master GTM artefacts inherit, never duplicate. cap_id field added to HARMONY_CALENDAR schema alongside persona_fk — at least one must be set per motion. Content classified as "market_education" (CAP-only) or "pipeline" (persona involved). |
| DEC-MGTM-NEW-10 | Filter Card timing — at Content Command draft stage (preventive) or final-asset stage post-CON-003/004/005/006 (gate)? | OPEN | Both technically defensible (Filter's nine tests don't require visual signal). Affects where FILTER_PASSES log is written and how rework loops sequence. Needs cross-team confirmation with Content Command builders + Nucleus production owners. Listed in §9 questions for the Content Command team. |
Vocabulary updates — sub-GTM → Service GTM
Pass through Spine cross-references, Cascade Execution Guide, Reef Briefing HTML §4, Master Task Register, and memory entries. Rename the sub-gtm-builder skill (T-MGTM-091) → service-gtm-builder.
Spine §6 Content Portfolio — add T1/T2 structural cut
Spine §6 currently holds the content portfolio mix. Update v1.1 cut adds the T1 (direct, ~30%) / T2 (thematic, ~70%) split as the structural cut, with the five Pillars as territories within the split.
Channel Matrix — add Pillar column + AIDAR row
Current matrix is Position × Channel. v1.1 cut adds Pillar as a tag dimension and AIDAR stage as a row dimension so the matrix tells you what AIDAR stage activates which Position on which channel for which Pillar.
Filter Card v1.2 — banned terms + structured sidecar
Add "In today's digital landscape" and "results without metric+timeframe+context". Emit filter-card.json alongside the HTML. Schema as defined in §4 boundary object 2.
Harmony Calendar Airtable schema — additional fields
Add track, pillar, aidar_stage, persona_fk, position_strengthened (multi-select), filter_pass_fk, reactive_origin. Schema as defined in §4 boundary object 3.
Cascade Execution Guide — DT-29
Add Decision Trail entry DT-29 codifying the bookend model and pointing to this alignment doc as the canonical contract reference.
Nucleus Block Map — annotate CON-002 only
Mark CON-002 Editorial Calendar as "implemented as Content Command (React app)". CON-003, CON-004, CON-005, CON-006 remain as separate Nucleus production blocks downstream of Content Command — those build the actual visual / video / lead-magnet / social-distribution assets. (Earlier reading that conflated all five into Content Command was wrong; corrected per cross-check against the Nucleus block files.)
CAPs propagation across cascade artefacts
CMIF is canonical for Content Audience Profiles (C1–C4 already exist there at lines 1090–1219). Cascade artefacts that need to inherit, not duplicate: Channel Matrix adds CAP as a tag dimension alongside Pillar; Harmony Calendar Airtable schema adds cap_id field with constraint that persona_fk OR cap_id must be set; Spine §6 Content Portfolio adds a paragraph distinguishing pipeline content (persona-tagged) vs Market Education Content (CAP-tagged); Reef Briefing HTML §1 references CAPs alongside Personas in the audience model.
Filter Card timing — DEC-MGTM-NEW-10 open
Whether Filter Card runs at Content Command draft stage (preventive) or at final-asset stage post-CON-003/004/005/006 (gate) is unresolved. Affects FILTER_PASSES write timing + rework loop sequencing. Listed in §9 question 1 for the Content Command team. No further propagation work happens on the Filter Pass surface until this is resolved.
Service-gtm-builder skill — clear target output spec
Skill now has a defined target shape: produce documents in the Service GTM schema (§4 boundary object 1) so Content Command can ingest them on upload without parsing ambiguity.
For Master GTM stewards (Gem, future Marketing Lead)
Before adding a new test, banned term, taxonomy, or schema field — check §3 contracts and §4 boundary objects to see whether it requires a downstream change to Content Command. If yes, push the change through the boundary object (sidecar, schema migration) rather than as an HTML-only update.
For Content Command builders
Before adding a new content attribute, taxonomy, or quality rule to the app — check whether the cascade already has a canonical home for it. If yes, pull from the cascade (sidecar, Airtable, Service GTM schema) rather than maintaining a parallel definition. If no, propose it as a cascade addition first; once accepted, it lands in the appropriate cascade artefact and Content Command consumes it.
For the marketing layer (Yohance, Anyah, Kevyn Barcelon)
You don't need to memorise this document. You need to know: the Master GTM tells the system what content to make, Content Command does the planning and drafting, and the Filter Card runs the gate. When something feels off — a banned term you're sure isn't banned, a Pillar that doesn't fit a piece you're working on — flag it. The flag becomes a cascade discussion, then a cascade update, then a Content Command sync. The system improves through use.
For Stephan (founder)
This is the contract that prevents the marketing function from drifting into two parallel disciplines. Master GTM holds doctrine; Content Command holds execution; the contract holds them together. Posture Gate ratifies any change to the contract that would shift Webgold's strategic stance (e.g. a new claim, a new position, a new authority territory).
Required changes — what needs updating in the app
Re-source from Notion brand system
Track 1 currently #E8593C; Track 2 currently #1B8C7A. Source of truth is the Webgold brand system in Notion. Update both hex values to match Notion-canonical brand orange and brand teal. Apply across UI without exception. Why it matters: visual brand drift between Content Command and the rest of Webgold's surfaces erodes the "we are the proof" claim — both tools have to match the same brand before that claim is credible.
Add five terms to the content-engine block list
Filter Card v1.1 added five banned terms not currently in Content Command's list: AI-powered, AI-driven, powered by AI, AI-first (as self-claim), better than (any named competitor). Add to Content Command's content-engine guardrails so generated content never carries these terms forward. Why it matters: if Content Command generates content with these terms, the cascade gate will reject it — wasted Gemini cycles and rework loops. Sync prevents that.
Add cap_id alongside existing persona FK
ContentItem and StockpileItem schemas need a new field cap_id (single-select: C1 Local Digital Consumer · C2 Diaspora Buyer · C3 Pre-Store Entrepreneur · C4 Social Commerce Seller). Either persona_fk OR cap_id must be set per content item (or both — they're independent lenses). Pipeline content typically uses persona only; Market Education Content uses CAP only. Currently the brief references C3/C4 only in P2 audiences; all four CAPs need to be exposed in the content engine so market-education content can be properly scoped. Why it matters: Market Education Content is tracked separately (reach/engagement, not MQL) and contributes to DX Authority — the schema needs to support both content classes natively.
Add inheritsFromSpine: true + masterGtmVersion
When the Master GTM authors a Service GTM (via the service-gtm-builder skill, T-MGTM-091), the document includes inheritsFromSpine: true and masterGtmVersion: "Spine v1.0" as top-level fields. Content Command's GTM ingest needs to read and preserve these fields. Why it matters: makes the doctrine binding explicit and version-trackable. If Spine moves to v1.1, Content Command can flag Service GTMs still bound to v1.0 for review.
Add a phase before "Polish" for Airtable read/write integration
Current phase order ends with "Phase 7 · Polish, health dashboard, export" all running on localStorage. A new phase is needed for Airtable sync — Content Command localStorage stays as working cache, Airtable becomes ground truth. On every Content Command launch and silent refresh, Airtable data overrides local state for fields like status, scheduled_date, filter_outcome. Gem builds this side, but Content Command needs to expose the right hooks: a sync API surface, conflict-resolution for offline edits, and read-through caching. Why it matters: without sync, Content Command and the Master GTM Harmony Calendar drift. Two calendars, two truths.
ACT NOW news → HARMONY_CALENDAR row with reactive_origin = true
When Caribbean RSS news is triaged ACT NOW and added to Track 2, the spawned motion needs to land as an Airtable HARMONY_CALENDAR row with reactive_origin = true, track = "T2", source URL captured. Likely target audience is a CAP (C1–C4 — market education) more often than a buyer persona. Why it matters: reactive content is a distinct strategic asset class; tracking it lets us measure what proportion of motions are reactive vs planned, and assess whether the reactive feed is producing high-leverage motions or noise.
Switch quality enforcement to filter-card.json
Filter Card v1.2 will emit filter-card.json as a structured sidecar (schema in §4 boundary object 2). When it ships, Content Command's content-engine quality enforcement needs to read from that sidecar instead of a hardcoded list. Why it matters: single source of truth. When Filter Card adds a banned term, Content Command sees it the same day — no parallel lists drifting out of sync.
Questions to confirm with the Content Command team
At what stage does the Filter Card pass run?
Two valid architectures: (a) at Content Command draft stage — preventive, kills bad copy before downstream Nucleus production; (b) at final-asset stage post-CON-003/004/005/006 — gate, final check on assembled motion. Both technically defensible (Filter's nine tests work on copy + plan alone). Decision affects where FILTER_PASSES log is written and how rework loops sequence. Confirmation needed before §3 contract 7 can fully ship.
Is there a hardcoded brand voice document inside Content Command?
Per Master GTM DT-4, Filter Card overrides the standalone Brand Voice document where they conflict. If Content Command currently has a separate hardcoded brand voice, it conflicts with that ruling. Confirm Content Command pulls voice rules from Filter Card sidecar (when v1.2 ships) — not from a parallel internal doc.
Are all four CAPs exposed in the content engine, or only C3/C4?
The brief references C3 and C4 in P2 (Regional Commerce & Trust) audiences. C1 (Local Digital Consumer) and C2 (Diaspora Buyer) are also CMIF-canonical and should be available. Without all four, Market Education Content for diaspora-buyer audiences can't be tagged correctly.
Does the Gemini parser accept structured JSON, or only freeform docx/txt/md?
Determines what shape the service-gtm-builder skill should emit. Structured JSON is cleaner (no parsing ambiguity); freeform docx is friendlier UX. Likely answer: docx for human-uploaded GTMs + JSON for skill-emitted GTMs. Confirm.
Is "Diagnose → Design → Deliver → Sustain" hardcoded anywhere?
It's the Webgold service methodology (per CMIF) and is compatible with Master GTM doctrine — but if it's hardcoded as a structural element in the content engine, it should be soft-referenced from CMIF (which is the canonical source) rather than embedded in the app code.
What does the Phase 7 health dashboard track?
If it tracks T1/T2 ratio, AIDAR distribution, Pillar coverage — those are cascade-aligned and should be exposed to the Master GTM Harmony Calendar surface as well. If it tracks separate brand-voice-compliance metrics, those should fold into the Filter Pass rate from FILTER_PASSES Airtable rather than being computed independently.
Where exactly does Content Command's responsibility end?
Status flow goes Idea → Brief Approved → In Development → Ready → Scheduled → Published. Where in that flow does the asset hand off to CON-003 (Core Visuals), CON-004 (Video Shorts), CON-005 (Lead Magnet), or CON-006 (Social Distribution) for production? "In Development" likely = handed off; "Ready" = production complete. Confirm so the Nucleus block ownership boundary is explicit.
Required changes 1–7 are work for the Content Command team. Questions 1–7 are conversations Gem (or whoever runs the cross-team meeting) needs to have to close open architectural questions before the alignment doc moves from v1.1 to v2.0. None of this blocks Master GTM artefacts from continuing to evolve internally — but the contract holds only as long as both sides converge on the answers.