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, 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.

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.
• 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.

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 public ontology pages. 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 for internal use — these entries are part of the catalog but are not yet exposed via the public JSON / MCP either, since the live runtime endpoint surfaces only KPIs with an attached definitionSource (today, all published-tier). As more entries get back-attributed (see epic #1415), they appear in the live endpoint and on this site.

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.

3. How to consume each surface

The catalog is published through three surfaces; pick the one that matches your use case. The numbers below shift as the catalog grows — the hub page shows the current totals at the top.

Industry-backed (tier: "published") — MDX pages, JSON, and MCP

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 (SMSB, KBCM, Carta, Mercer, SaaS Capital, Retently, NVCA, YC SAFE, SHRM). These pages are the human-readable spec — they cite the source, link the canonical page, and surface any verbatim attribution notice the publisher requires. The same set is exposed live via JSON and MCP:

# Full live catalog — published-tier only, no auth, plain JSON
curl https://app.imboard.ai/api/ontology.json | jq 'length'

# Filter to one domain
curl https://app.imboard.ai/api/ontology.json \
  | jq '[.[] | 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.

• get_rogue_kpi({ rogueId }) — fetch a single KPI by its canonical rogueId (e.g. 'finance.arr').

• Find them: the Board Ontology hub groups them by domain; each per-domain index lists every 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.

I'mBoard-authored (tier: "editorial") — not yet exposed publicly

I'mBoard-authored KPIs are part of the catalog but do not appear as MDX pages here, and are not yet exposed via the public JSON / MCP either — the live runtime endpoint surfaces only KPIs with an attached definitionSource (today, all published-tier). As more entries get back-attributed (see epic #1415), they appear in the live endpoint and as MDX pages here.

When you query the runtime endpoint or MCP today, you get the cited published-tier catalog only:

# Today returns the published-tier catalog (cited KPIs) — no editorial yet
curl https://app.imboard.ai/api/ontology.json | jq '[.[] | .definitionSource.tier] | unique'
# => ["published"]

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 industry-backed (published-tier) catalog only today; the docs snapshot mirrors the MDX pages exactly, and the runtime reflects new attributions sooner. Editorial-tier KPIs aren't surfaced on either — see epic #1415 for the back-attribution workstream that closes the gap.

4. 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.

5. 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.

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.

6. 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 catalog. When the underlying standard catches up or I'mBoard's calculation reconverges, the KPI is re-anchored to the industry-backed source and the I'mBoard-authored entry is retired with a note in the change log.

I'mBoard-authored KPIs are part of the catalog and surface in the product, but they do not appear as MDX pages on docs.imboard.ai/docs/ontology and they are not yet exposed via the live runtime JSON / MCP either — the runtime endpoint serves only KPIs with an attached definitionSource (today, all published-tier). See epic #1415 for the back-attribution workstream that closes the gap.

7. Versioning and change control

Section 3 above covers how to consume each surface. This section covers stability — how each surface evolves over time and which one to pin against.

Definitional changes are tracked in the source registry. A non-cosmetic change to a KPI's definition text bumps the catalog's version; partners depending on a specific revision should pin to the docs snapshot.

8. 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.

9. 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.