Looking for one tool rather than the whole model? METRIVANTA Atlas lights up a single tool’s slice inside the graph — same shared renderer as the per-tool maps on the platform.
Internal document. Enter the access password, or sign in with your Digimetrics Google account.
Digimetrics.ai · METRIVANTA™ · complete pack — vision, expert graph, action stack & build plan · August 2026
Everything in one place: the plain-English story, the Sense→Model→Score→Prioritise→Learn loop mapped onto our live stack, the interactive Expert Graph (80 nodes, 182 weighted edges — click any node), a fully worked Action Stack, and the six-week implementation plan for platform.digimetrics.ai and app.digimetrics.ai. Every percentage in here is an expert prior for the consultants’ workshop to challenge and for the Learn stage to refine.
Think of Metrivanta as a sat-nav for marketing. The map is our consultants' playbook, written down once ("if bounce rate is high, suspect page speed; after a site audit, check speed next; if ads get pricey, look at who else is bidding"). Crucially, every connection on the map carries a percentage attribution — e.g. when bounce rate is high, we attribute 70% suspicion to page speed, 50% to mobile experience, 35% to thin content — and the ranking formula itself is percentages (25% commercial impact, 20% strength of evidence, 15% chance of success, and so on). Your position on the map comes from the tools we already run — each one will raise simple flags like "site is slow" or "invisible to ChatGPT". The route is the Action Stack: a to-do list ordered by those percentages, with a plain reason attached to every item. And like live traffic, it learns: every time someone does or skips a recommended step, and every time a client's numbers move, the percentages get corrected — that is the "always closer to the truth" mechanism in the vision.
Concretely, over six weeks: (1) write the playbook into one master file both products read; (2) teach six tools to raise flags; (3) make the "what next" suggestions under every report react to those flags instead of being fixed; (4) turn the existing Plans feature into the ordered Action Stack; (5) give consultants and the chatbot the same brain; (6) track one number weekly — do people actually do the top three things we recommend? Nothing is thrown away and no new product is built from scratch: every step upgrades something that already exists and works.
This document was written as a plan. Most of it is now running. Everything marked Shipped is live on the surface named and was built against this graph — the same artefact the explorer below reads. The plan sections further down keep their original wording, with each step carrying its real status, so the diff between what was proposed and what was built stays legible.
Ten of twelve steps are shipped. B5 is deferred on purpose — auto-running effort-1 tools spends client credits, so it waits for a consent and metering design. A3 is the only thing blocking the WEIGHTING release, now v0.3 — v0.2 shipped separately as a structural change (paid media, social and content became first-class disciplines), so the room is re-weighting a bigger graph than this pack was first written against. It is not blocked on engineering: the prep pack, the sensitivity analysis that says which weights actually change the advice, and the weight tables below are all written and live. What it needs is three hours of consultants.
The graph grew, twice. v0.1 was seeded at 74 nodes and 156 edges. v0.2 then took paid media, social and content from appendices to full disciplines, and it now runs 118 nodes and 316 edges — the counts above and throughout this page are read from the published artefact at load, so they cannot drift again.
Two workshop assumptions did not survive contact. The prep pack was first written against a graph we do not run, which would have sent the room arguing about edges that do not exist. And once the sensitivity analysis was written, the measured answer for where the three hours should go was not the one this document originally proposed. Both are corrected in saas/docs/metrivanta-a3-workshop.md.
Re-ordering alone proved to be a no-op on one test account. B3 shipped only after the ordering was shown to change against a real account — the acceptance metric in B4 exists so that claim stays testable rather than assumed.
Component names in monospace are the actual Lambdas, pipelines, and data stores in production.
webpageAudit, dataforseoCrawler (AI Discovery Audit)LivegscIndexCoverage (18 properties)LiveahrefsProxy, backlink tracking toolLiveseo_kpi_daily_raw, GSC warehouse, budget-pacing history, campaign summaries on mondayLiveThe network below is the actual v0.1 seed, clustered by discipline. Circles are diagnostic states, squares are actions; node size tracks how connected a node is. Click a node to light up its neighbourhood and inspect its edges in the side panel; drag nodes to rearrange, drag the background to pan, scroll or use the buttons to zoom. Toggle edge types and discipline chips to declutter.
Click any node in the graph — or use the jump-to selector — to inspect its causes, remedies, next steps, and cross-discipline triggers here.
The examples from the original Metrivanta message, as they actually resolve in this graph — click any node to see it in the network above:
| Factor | Weight | V1 computation |
|---|---|---|
| Impact | 25% | Value at stake behind the addressed states — severity × commercial weight of the affected KPI |
| Evidence | 20% | 1 − Π(1 − wₑ) over all edges corroborating the action's target states — independent signals compound |
| P(success) | 15% | Weight of the addresses edge as prior; replaced by portfolio hit-rates in Phase 2 |
| Urgency | 10% | Elevated when an active threat-opportunity edge fires (competitor moving, algorithm update) |
| Speed | 10% | 1 / (1 + lag_days / 30) — from the action's expert-authored lag |
| Effort (inverse) | 10% | Expert-authored 1–5 per action, normalised |
| Risk (inverse) | 10% | Expert-authored 1–5 per action, normalised |
Weights sum to 1 and are themselves graph metadata — the consultants' workshop can re-balance them, and Phase 2 can tune them against the acceptance metric. Nothing here is hard-coded doctrine.
Every number Metrivanta ranks on, in one place, read live from the published artefact. Until now these were only visible as a by-product of diagnosing a specific client in the Action Stack — which meant a weight you wanted to argue about only appeared if some client happened to have that problem, and a healthy client surfaced nothing at all. This is the A3 workshop's working surface. Nothing here is doctrine: every value is an expert prior with a defined update path, and disagreeing with one is the entire point of the session.
Scores computed with the formula above from this graph's edge weights and action attributes; illustrative of mechanics, not client advice. Note what emerged without being programmed explicitly: the stack front-loads three same-week, high-evidence diagnostics, holds expensive fixes behind the diagnostics that de-risk them, and still surfaces the blue-ocean GEO opportunity a channel-siloed audit would never mention next to a PPC problem. That is the pitch, demonstrated.
Ontology workshop with consultants → weighted edge table → scoring engine → Action Stack on platform.digimetrics.ai, upgrading the Goal Planner and hand-off classifier. No ML.
Mine run-history transitions and outcome correlations; Bayesian weight updates pooled across the portfolio, with client type as a feature — not per-client models.
Algorithm-event ingester adjusts priors after updates; embeddings over node descriptions surface new adjacencies, not just reweighted known ones.
saas/ codebase)NEXT_STEPS in saas/shared/catalog.mjs — hand-authored tool→tool edges with "why" copy, rendered by NextSteps.jsx under every result, prefilled via carryValues.js. This is the next-step edge type, already shipped.lib/handoff.js + backend card.owner — every recommendation names its owner. The finding-normalisation layer.buildPathway + lib/planner.js / planStrip.js — goal → checklist plans with step done/skip state and Monty hand-off. The Action Stack's chassis.toolRun.js / jobRun.js, runs store) — the transition data Learn will mine.metricscron — an existing nightly aggregation Lambda to extend.index.html codebase)buildToolCatalog() — tools enumerated from nav data-card-section anchors; navigation via section ids.saas/shared/metrivanta.mjstoolId from TOOLS where one exists (technical-seo, page-speed, ai-mentions, ai-discovery, geo-onpage, llms-txt, backlinks, competitors, keyword-analysis, onpage, content-writer, landing-audit, rank-checker, strategy-engine…) and an owner from REC_OWNERS where none does (dev/agency work like CWV fixes, link building). Include version, the 7 score weights, and a traverse(states) → rankedActions helper so both surfaces share one scorer.saas/backend/scripts) emits metrivanta-graph.json to S3 on deploy. app.digimetrics.ai and the monday Lambda read that artefact. One source of truth; the five-place chatbot sync problem is not repeated here.saas/docs/metrivanta-a3-workshop.md, saas/backend/scripts/metrivanta-sensitivity.mjs.states: [{id, severity, evidence}], set server-side in each tool's adapter (same place card.owner is set — adapters are already the contract layer). Start with six: technical-seo (crawl errors, no schema, weak internal links), page-speed (slow speed, poor mobile), ai-mentions (low AI visibility), ai-discovery (AI blocked), backlinks (toxic links, low authority), onpage (thin/stale content). Thresholds documented in the adapter, not guessed in the frontend.NextSteps.jsx currently renders the static NEXT_STEPS shortlist. Change: when the run emitted states, rank suggestions by traverse() (evidence-weighted) and show the why-trail ("LCP 4.9s + bounce high → both point at page speed"); fall back to the static list otherwise. Keep 2–4 items — the existing rule stands.buildPathway with the user's recent run states (latestRuns.js) and let the Opportunity Score order the steps, each carrying its why-trail and score. Plans already have the checklist UI, deep links, per-step done/skip, and Monty hand-off for ownerless steps — that accept/skip toggle is the Learn feedback capture, free of charge. Respect the plan step sync contract when adding fields.metricscron to aggregate nightly acceptance-rate per action — the product's success metric from day one, before any weight learning exists.costUnits preview, tier gates). Phase 2, after the stack proves itself on runs the user started.renderMetrivantaNextSteps(states), appended to result output of four tools first: Webpage Audit, AI Mentions/GEO, Domain Analysis, and the SEM ad tools. Each suggestion deep-links via the existing section navigation (data-card-section ids from buildToolCatalog()). States mapped in each tool's render path — consultants see the same graph logic clients do.get_next_best_actions(states|domain) reading the S3 graph JSON. The chatbot can then answer "what should we do next for client X" with the same ranked, why-trailed list — no sixth knowledge copy, it calls the graph.app-core.js rather than inline in index.html (itself still ~117k lines). A single syntax error kills every tool. New code in small, self-contained functions; verify the whole block parses before push; mind concurrent sessions and the pre-commit hook re-staging the entire file.index.html under 10 MB — CloudFront only auto-compresses responses below that, with no error when it skips one. At 11.4 MB the page shipped raw while every smaller asset got brotli; splitting out app-core.js put both files under the line and cut transfer 10.9 MB → 2.6 MB. Do not pre-compress into the deploy bundle instead: Amplify rejects the artifact, as Content-Encoding is a readonly header.--template-url; any change-set rewrites AdminFn/AuthFn environment (re-apply out-of-band Meta creds).The consultants are the pretrained model. The doc's "deployed across thousands of campaigns" is true — in the consultants' heads. Phase 1's ontology workshop is the model download, so it is a structured, scheduled extraction exercise, not an engineering side-task.
Define the success metric on day one. Proposed: acceptance rate of the top-3 Action Stack items, and KPI lift of accepted vs. skipped actions. Without it, Learn has nothing to learn against and the Opportunity Score can never be shown to beat a static checklist — which is the product's whole claim.
Cheap diagnostics floating to the top is a feature. Every effort-1 action that maps to a live tool can be auto-executed by Sense the moment its edge fires — at which point the human-facing stack contains mostly interventions, pre-loaded with evidence. The graph decides what to run; the tools already exist to run it.
The gates are next-step edges doing double duty. "Fix CWV after the speed audit confirms scope" isn't a special rule — it falls out of the same edge type that encodes "site health → page speed". One mechanism, two behaviours.
Every number here is a Learn hook. 182 edge weights, 7 factor weights, 45 effort/lag/risk rows: each is an expert prior with a defined update path — accept/skip decisions and KPI outcomes nudge them Bayesian-style, pooled across the portfolio. The workshop's job is to make the priors defensible, not perfect.
From Increment 2 onward, one number goes in the weekly review: acceptance rate of the top-3 scored actions (platform.digimetrics.ai plan steps + consultant stack), alongside baseline acceptance of the static suggestions they replaced. If the graph can't beat the hand-written shortlist, the weights workshop has its agenda; if it can, Metrivanta has its first proof.