diff --git a/.github/workflows/methodology-version-check.yml b/.github/workflows/methodology-version-check.yml
new file mode 100644
index 0000000..d931e02
--- /dev/null
+++ b/.github/workflows/methodology-version-check.yml
@@ -0,0 +1,49 @@
+name: Methodology version check
+
+# The /methodology/ page serves the published specification address.
+# It fetches the latest transitrix/methodology release at runtime via JavaScript.
+# This check verifies that if the page is committed with a static version (for any reason),
+# it matches the current latest stable release.
+
+on:
+ push:
+ branches: [main]
+ paths: [methodology/index.html]
+ pull_request:
+ branches: [main]
+ paths: [methodology/index.html]
+
+permissions:
+ contents: read
+
+jobs:
+ check-methodology-version:
+ runs-on: ubuntu-latest
+ name: Methodology page version is current
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v4
+
+ - name: Fetch latest methodology release
+ id: methodology
+ run: |
+ RESPONSE=$(curl -s https://api.github.com/repos/transitrix/methodology/releases/latest)
+ TAG=$(echo "$RESPONSE" | jq -r '.tag_name')
+ VERSION="${TAG#v}"
+ echo "version=$VERSION" >> $GITHUB_OUTPUT
+ echo "tag=$TAG" >> $GITHUB_OUTPUT
+ echo "Latest methodology release: $TAG (v$VERSION)"
+
+ - name: Check page links to correct version
+ run: |
+ VERSION="${{ steps.methodology.outputs.version }}"
+ TAG="${{ steps.methodology.outputs.tag }}"
+ FILE="methodology/index.html"
+
+ if ! grep -q "$TAG" "$FILE"; then
+ echo "Error: methodology/index.html does not link to $TAG (latest release)"
+ echo "Page should link to: https://github.com/transitrix/methodology/releases/tag/$TAG"
+ exit 1
+ fi
+
+ echo "✓ Page correctly references $TAG"
diff --git a/methodology/index.html b/methodology/index.html
new file mode 100644
index 0000000..5870e02
--- /dev/null
+++ b/methodology/index.html
@@ -0,0 +1,115 @@
+
+
+
+
+
+
The published methodology
+
Loading version...
+
+
+
+ The Transitrix methodology is a published, open specification: Architecture-as-Code for the enterprise — the git-native, text-first discipline software already has, carried up to the strategy, business and architecture layers that code-scoped tools never reach.
+
+ What the specification covers
+
+ The specification defines the notations, validation rules, and patterns for enterprise-layer text-first modeling:
+ purpose-built notations for processes, goals, capabilities, applications, strategy and behaviour;
+ a schema-validation framework to catch invalid models at author time;
+ patterns for common decision flows and architectural questions.
+
+
+ Versions and stability
+
+ The specification follows semantic versioning. Major releases ship a migration recipe for existing models, not a release note.
+ A major release is the right time to adopt breaking changes that improve the language; the recipe walks you from any prior major to the current one.
+
+
+ Read the full specification
+
+ Read the full methodology specification on GitHub — the specification is maintained as a published release alongside the toolkit source code.
+
+
+
+
+
+
+
+
diff --git a/sitemap.xml b/sitemap.xml
index b5116ac..02cfe02 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -58,6 +58,10 @@
https://transitrix.com/recipes/
diff --git a/what-can-i-model/index.html b/what-can-i-model/index.html
index b5828f7..67bb673 100644
--- a/what-can-i-model/index.html
+++ b/what-can-i-model/index.html
@@ -54,7 +54,7 @@ What can I model?
Transitrix ships a set of purpose-built notations rather than one generic shape you bend to fit everything: BPMN and process blueprints for how work happens; goal trees, capability maps and FGCA for what the organisation is trying to do and what it can do; application and product notations for the systems landscape; activity networks and scenarios for behaviour over time.
Each notation is built for its own layer, business or technical, instead of being a stripped-down copy of a general-purpose diagram.
- See one minimal, schema-valid example of every notation on the DSL examples page, or the full specification for each in the methodology repository.
+ See one minimal, schema-valid example of every notation on the DSL examples page, or the full published methodology specification.