Methodology

The I'mBoard Board Ontology (codename Rogue) publishes canonical definitions for the metrics that appear on a startup board agenda. This page explains why every entry cites a source, how the industry-backed vs I'mBoard-authored tier system works, how versioning and immutable snapshots work, what SMSB attribution requirements look like in practice, and how the catalog evolves over time.

It is meta-documentation. For the metrics themselves, see the Board Ontology hub. For per-release notes, see the changelog.

1. Why we cite sources

Most board tools render metrics without saying what they mean. "ARR" alone has at least three common definitions in circulation — contracted ARR at a point in time, recognised ARR over a trailing window, and a normalised "committed ARR" that strips one-off line items. Without a citation, the reader cannot know which one a dashboard is showing, and the board cannot debate variance against a stable baseline.

Attribution exists to remove that ambiguity:

• Defensibility. A KPI cited to a published standard can be defended in a board meeting, audited by a finance team, and reproduced by a third party. An un-cited KPI cannot.
• Stability. A cited definition only changes when the source changes, and we can show the diff. An un-cited definition drifts silently between product releases — that is what the versioning section below addresses.
• Interoperability. When two tools cite the same standard for the same metric, the metric means the same thing in both. That is the precondition for portable board reporting.

Citations are not a marketing flourish. They are a contract between I'mBoard and anyone reading a metric on a board pack.

2. The two tiers — industry-backed vs I'mBoard-authored

Every KPI in the catalog carries a definitionSource block whose tier field is either published (industry-backed) or editorial (I'mBoard-authored). The JSON field names date to the catalog's first release; the labels below are how we describe the tiers everywhere else. Both tiers ship via the public JSON / MCP surface — the tier is information, not a gate. Strict-mode consumers filter to published client-side.

Industry-backed (tier: "published" in the JSON)

The definition is anchored to a named, externally-published standard. I'mBoard cites the standard by name, links the canonical page, and surfaces any attribution notice the publisher requires. Examples of sources that qualify today:

• SaaS Metrics Standards Board (SMSB) — the primary definitional standard for SaaS metrics.
• KBCM/Sapphire SaaS Survey — KBCM's annual survey publishes both metric definitions and benchmark distributions; we cite it for KPIs that map to its benchmarks.
• SaaS Capital Annual Survey, Mercer US Turnover Survey, Carta State of Private Markets, and Retently NPS Benchmarks for non-SaaS-specific or domain-specific metrics where each publication also defines the metric.

Industry-backed (published) KPIs are emitted as dedicated MDX pages on this site. If you can read it on docs.imboard.ai/docs/ontology, it has an authoritative third-party source behind it.

I'mBoard-authored (tier: "editorial" in the JSON)

A significant share of board-critical KPIs have no public, canonical definition today. Rather than ship a metric you can't defend, I'mBoard authors the definition explicitly and labels it editorial so consumers can see exactly which definitions are I'mBoard's view and which are externally anchored. Editorial-tier KPIs ship in the public JSON / MCP alongside published-tier ones — the tier label is the consumer's filter.

Editorial-tier entries don't yet have dedicated MDX pages on this site (anti-bloat: per-page cost is high relative to the marginal benefit when the only citable source is I'mBoard itself). When a public standard catches up — or I'mBoard's calculation reconverges with a candidate standard — the KPI is re-anchored to the standard and promoted from editorial to published, at which point a dedicated MDX page lands too. Promotion progress is tracked in epic #1415.

3. How to consume each surface

The catalog is published through three surfaces; pick the one that matches your use case.

Both tiers — live JSON and MCP

app.imboard.ai/api/ontology.json and docs.imboard.ai/api/ontology/index.json both return the full catalog (both tiers, tier-labeled) wrapped in a versioned envelope:

{
  "version": "1.3.0",
  "releasedAt": "2026-05-20",
  "kpis": [
    { "rogueId": "sales.arr", "definitionSource": { "tier": "published", ... }, "calculationPolicy": { ... }, "metricBasis": { ... }, ... },
    { "rogueId": "product.activation_rate", "definitionSource": { "tier": "editorial", ... }, ... }
  ]
}

# Full live catalog — all tiers, no auth, plain JSON
curl https://app.imboard.ai/api/ontology.json | jq '.kpis | length'

# Strict mode — filter to published-tier client-side
curl https://app.imboard.ai/api/ontology.json \
  | jq '[.kpis[] | select(.definitionSource.tier == "published")] | length'

# Filter to one domain
curl https://app.imboard.ai/api/ontology.json \
  | jq '[.kpis[] | select(.domain == "finance")]'

For AI agents speaking MCP, the I'mBoard MCP server exposes two tools that return the same shape (see the Claude Code & MCP guide for setup):

• browse_rogue_kpis({ domain, maturity, suggestedForStages, search }) — list/filter the live catalog (both tiers).
• get_rogue_kpi({ rogueId }) — fetch a single KPI by its canonical rogueId (e.g. 'finance.arr'). Returns either tier.

Industry-backed only — MDX pages

This is what you're browsing right now. Every page under /docs/ontology/{domain}/ is an industry-backed KPI: I'mBoard's description is anchored to a named, externally-published standard. These pages are the human-readable spec — they cite the source, link the canonical page, and surface any verbatim attribution notice the publisher requires.

• Find them: the Board Ontology hub groups them by domain; each per-domain index lists every published-tier KPI in that domain.
• Why MDX: an industry-backed KPI carries enough attribution metadata (source name, URL, section reference, publication date, optional verbatim notice) that surfacing it as a citable page is worth the per-page cost. Editorial-tier KPIs don't yet — they're accessible via JSON / MCP only until they're re-anchored.

Live updates

The catalog has two different update cadences. Pick the one your integration cares about:

Both surfaces are public and unauthenticated. Both serve the full catalog (both tiers) today — the docs snapshot mirrors the JSON state at build time, and the runtime reflects new attributions sooner.

A machine-readable JSON Schema for these responses is published at /api/ontology/schema.json — validate index.json against #/definitions/OntologyResponse, {domain}.json against #/definitions/OntologyDomainResponse, and {domain}/{slug}.json against #/definitions/OntologyKpiResponse. It is generated from the same TypeScript types the catalog serializer uses, so it never drifts.

4. Versioning and immutable snapshots

Every response is wrapped in a versioned envelope: { version, releasedAt, kpis } (or { ..., kpi } for per-KPI). version follows semver:

• Patch (1.0.0 → 1.0.1) — typo, description tweak, formula clarification, attribution rewording. No consumer impact.
• Minor (1.0.0 → 1.1.0) — new KPI added, KPI promoted editorial → published, new optional field on OntologyKpi. Additive only.
• Major (1.0.0 → 2.0.0) — KPI removed, rogueId renamed, required field added, envelope shape changed. Consumers must update.

The maintainer picks the bump in the release PR — there's no auto-bump. That deliberate friction is what makes the version meaningful.

Pinning to a version

Every release publishes an immutable snapshot alongside the live URL. Pinning to a versioned URL guarantees the response shape and contents never change for that version:

Per-domain and per-KPI variants follow the same pattern under /v/<version>/{domain}.json and /v/<version>/{domain}/{slug}.json.

The changelog records every release with added / removed / promoted / changed KPIs. Pin against a snapshot URL if your integration cares about reproducibility — for example, board packs generated by an agent should pin to the version that defined the KPIs at report-generation time, so reviewers can reconstruct exactly what "NRR median" meant when the report ran.

5. Calculation policy — the agent-safe execution contract

Sections 1–4 cover what a metric means and which version you're looking at. They don't cover how an AI agent should compute the metric from a company's actual data. That gap is where most agent-generated board packs go wrong — confusing ARR with CARR, using net new ARR including expansion in CAC payback, off-by-12 monthly conversion errors.

As of v1.1.0, each KPI optionally carries a calculationPolicy block alongside description, formula, and interpretationGuidance. Its sole purpose is to tell an LLM agent how to compute the metric correctly from messy company data.

Subfields

All subfields are free-text string arrays, consumed by LLM agents at reasoning time. The audience is reasoning models, not a deterministic computation engine — a structured DSL would force premature formalization and (per our experience with prior schema attempts) drift away from how analysts actually describe these rules.

Coverage

calculationPolicy is being rolled out in batches, highest-leverage metrics first. v1.1.0 seeded the first 5 KPIs (the core ARR and retention metrics); v1.2.0 extended coverage to 25 KPIs, adding the rest of the ARR waterfall, the CAC family, and cash/runway — the metrics most likely to be miscomputed in agent-generated board packs. The remaining 118 KPIs do not yet carry a calculationPolicy block; the field is optional and omitted entirely from the JSON when absent — unenriched KPIs emit the same shape as in v1.0.0. The changelog lists the exact KPIs added in each release.

Subsequent batches are produced with a draft pipeline (packages/shared-types/scripts/draft-calculation-policies.ts): it asks an LLM to draft a policy from each KPI's existing fields, but every draft goes through a non-optional human review — tightening commonMiscomputations and verifying inclusion/exclusion rules against the cited source — before it ships. Each editorial → published promotion (see epic #1415) is also a natural moment to populate calculationPolicy, and new KPI additions gain a policy when they ship.

How agents should use it

When an MCP-aware client asks an AI agent to compute a KPI:

1. Fetch the KPI via get_rogue_kpi({ rogueId }) or /api/ontology/{domain}/{slug}.json.
2. If calculationPolicy is present, surface its commonMiscomputations to the user before running the calculation — they are the cheapest way to catch a bad result before it lands in a board pack.
3. Treat inclusionRules / exclusionRules as boundary conditions on which source-data rows enter the calculation.
4. Apply validationChecks to the computed result before returning it.
5. If calculationPolicy is absent, fall back to formula + interpretationGuidance and explicitly note the absence in any output that renders the metric.

How disputes are handled

Errors in a calculationPolicy (e.g. an inclusionRule that conflicts with the cited source standard) are handled under the same disputes flow as §11. Per-policy edits are a patch bump when they tighten an existing rule, a minor bump when they add a new rule or subfield, never a major bump (additive change to optional content).

6. Metric basis — structured, machine-filterable measurement metadata

Where calculationPolicy (§5) is free-text guidance an LLM reasons over, metricBasis is a small set of enum axes a consumer can filter on deterministically — "all point-in-time metrics", "all cohort-based metrics", "all metrics measured on a cash basis". No prose, no parsing.

As of v1.3.0, each numeric KPI optionally carries a metricBasis block with up to five axes:

Each axis is independently optional and omitted when not meaningful — a KPI carries only the axes that apply, and the whole metricBasis block is absent on narrative (text) KPIs. Like calculationPolicy, the field is optional, so consumers that ignore it see the same JSON shape as before (additive — a minor version bump). The enum values are part of the published JSON Schema, so a consumer can filter the catalog without guessing at string values.

7. SMSB attribution — verbatim requirements

Every industry-backed KPI whose source is the SaaS Metrics Standards Board surfaces the following attribution notice, verbatim, on its KPI page:

The wording is fixed. We surface it whenever we render an SMSB-anchored KPI, in both the public docs and any internal product surface that exposes the underlying definition.

What we do not do, by policy:

• We do not use the SMSB logo or trust badge.
• We do not claim certification, membership, or endorsement.
• We do not reproduce SMSB's definitional prose verbatim. We link to it.

This policy lives in code at packages/shared-types/src/data/definition-sources/definition-source-catalog.ts and is shared by every surface that renders an SMSB-sourced KPI.

8. How definitions are sourced

The current industry-backed sources are listed in Section 2. The process for adding a new industry-backed source is deliberately small:

1. Vet the source. It must be publicly available, named, and stable enough that we can link to a canonical page or PDF.
2. Check attribution terms. Some publishers (notably SMSB) require a specific attribution string and forbid logo use. Those rules are captured in the source's catalog entry and enforced everywhere the source is rendered.
3. Deep-link the section. Where the standard exposes per-metric pages (SMSB does), the source mapping records a pagePath so each KPI page deep-links to the exact definition rather than to the publisher's home page.
4. Map the rogueId. Each affected KPI's rogueId gets an entry in rogue-definition-source-mapping.ts pointing to the new source. Promotion (editorial → published) is a minor version bump.

We deliberately do not copy the source publication's definitional prose into our KPI pages. Three reasons: fair use is bounded; our pages drift if the source updates and we forget to follow; and a deep link is more useful to the reader than a copy.

9. I'mBoard-authored tier — when I'mBoard publishes the definition

A KPI lands in the I'mBoard-authored tier (tier: "editorial" in the JSON) when:

• No public standard for that exact metric exists today, or
• A candidate public standard exists but the wording is ambiguous enough that we cannot defend it as-cited, or
• A standard exists but I'mBoard's calculation diverges in a way the standard does not anticipate (we treat divergence as a signal to author an I'mBoard-authored definition until the standard catches up).

I'mBoard-authored definitions are versioned alongside the rest of the catalog and surfaced in the live JSON / MCP. When the underlying standard catches up or I'mBoard's calculation reconverges, the KPI is re-anchored to the industry-backed source — a minor version bump — and a dedicated MDX page lands on this site as part of the same release.

10. Community contributions

We plan to open a contribution flow where the community can submit KPI proposals, source updates, or definitional clarifications via pull request. This is not available today and we are not committing to a shipping date. If you are interested in contributing, watch the imboard-monorepo repository or open an issue describing what you would like to contribute — that discussion will shape how the flow is designed.

11. Disputes

If you believe a definition, a citation, or an attribution is incorrect, file an issue on the imboard-monorepo issue tracker with the rogue ID of the KPI, the disputed claim, and what you believe the correct definition or citation should be. We triage ontology disputes explicitly — they are not folded into the general bug queue.

For non-public discussion (e.g. licensing concerns from a cited publisher), reach the maintainers directly at the contact listed on the imboard homepage.