AI Tools

Full metric details: definition, the canonical GASP grammar formula, Operating and Market forms, the Adjusted variant where one exists, benchmarks, signal type, recommended sensitivity tier and access scope, common mistakes, sources and page URL. A name several departments share returns each candidate with its department. Falls back to glossary terms when no metric matches.

Glossary terms such as Signal Type, Sensitivity Tier, Access Scope and Metric Owner: full definition, reference link and page URL.

List all metrics grouped by department and category, optionally filtered by department or signal type (outcome, leading, efficiency or operational).

The canonical formula in the GASP formula grammar, with its unit, Operating and Market forms, named variants and breakdowns, the metrics, fields and datasets each form reads and the enum filters each form applies. Metrics that cannot be computed carry the reason.

Upstream (what drives it) and downstream (what it drives) connections from the GASP relationship graph, for a metric, an entity or a concept. For an entity it also lists every metric whose formula reads the entity's data.

Data requirements for a metric or a department dashboard: each field the canonical formula reads with its type and the GASP dataset it comes from, whether the metric needs a staged dataset, reporting grain, source system and example SQL. Pass a breakdown the metric declares for one row per value, or a dialect for the SQL in your warehouse's syntax.

Whole-word search over metric names, aliases, definitions and formulas, glossary terms and the fields each metric needs. Returns up to 10 results, one per metric or term, with name and alias hits ranked first and each hit's page URL. A misspelling returns the closest names as "Did you mean".

Compile SQL for a metric from its canonical formula and your adapter mapping: one subquery per aggregate, each on the table you mapped to its GASP dataset. The dialect follows your adapter's warehouse (Postgres, Snowflake, BigQuery or Databricks; Postgres SQL also runs on Redshift) unless you pass one. Fields you have not mapped stay as {{field@dataset}} placeholders naming the dataset the column must come from. A breakdown returns one row per value.

Validate a warehouse mapping in either format: a GASP adapter (JSON) or an Apache Ossie mapping document over your semantic model. An adapter is converted on load into an Ossie mapping. The report comes in layers: the schema, the cross-document checks against the GASP ontology, then coverage: unknown fields and datasets, fields mapped to a dataset that lacks them, datasets whose fields point at different tables, every metric scored as fully covered, partially covered or not covered, enum fields mapped without a transform, covered metrics with no declared owner and the next mappings to add. validate_adapter is the same tool under its original name.

Compile the GASP metrics your mapping covers into your Apache Ossie semantic model. Same input as validate_mapping; returns your model with a gasp_ metric for every covered formula entry: a direct expression over your datasets and fields where the expression language can state it, else a staged per-period dataset whose source is the compiled SQL over your tables in your warehouse dialect, reading a period spine table you name. Entries with unmapped fields are listed with what they need, and recompiling replaces the earlier additions.

Score how far your own metrics drift from the canonical definitions, by result. Each metric in your semantic model is matched to a GASP metric by exact name, by the synonyms in its ai_context or by a pair you pass; near names are listed for review and never scored on a guess. The canonical metric is compiled into your dataset and field names and both run on the GASP synthetic SaaS dataset for six monthly periods, in an in-process Postgres. Where the numbers differ you get both values per period and the likely cause read from the canonical formula: a null on one side (a sum over no rows that is NULL in your SQL and 0 in GASP's), a cohort or opening value the expression cannot state, a filter one side applies, a dataset one side reads or an aggregate with no equal on the other side.

Profile your warehouse schema into a minimal Ossie semantic model, the first step towards a mapping. Pass the rows of information_schema.columns (JSON or CSV), a tables list or CREATE TABLE statements, read through your own warehouse MCP or from a dump, and optionally statistics per column; output: statistics returns the query that gathers them. Every table gets a key, a time field and a kind (snapshot, event, fact or reference) with the evidence and a confidence, plus the relationships the columns imply. What the names cannot settle is listed as a question for you rather than guessed. The model comes back as YAML to pass on as semantic_model.

Propose a GASP mapping from the model profile_schema returned, your own Ossie model or a schema profiled on the way in. Every table is scored against the GASP datasets on its columns, its profiled kind, key and time field and its name; every column of a proposed table against the dataset's fields by name, structural role, a short synonym list, word order and near names, checked against the type and the listed values. A column in cents gets a divide-by-100 transform and values the standard does not use a CASE recode when one is known. High-confidence pairs become an Ossie mapping over the model, ready for validate_mapping; medium ones are listed as candidates with their evidence and what would settle them.

Record the decisions people make on a proposed mapping, each named by content with its owner and date: a profiler question answered (the key, the time field, the kind or a datatype, written into the model), a candidate accepted or rejected (a table as a GASP dataset with its columns matched as the proposer would, a column as a GASP field with an optional transform), a metric owner (the slot validate_mapping reads) or a judgement call GASP cannot apply, such as the reporting currency or what date marks churn. Every decision lands in the mapping's GASP extension; a later one on the same subject replaces it. With no decisions it lists what is still open and whether readiness level 2 is reached.

SQL that derives CEL Revenue_Event rows from your subscription ledger, by the rules in the CEL. Most billing systems hold subscriptions, not events: the subscription dataset your mapping covers, as snapshots at any cadence or a version history, becomes one event per movement, with the customer's prior_mrr and new_mrr chained so the row identity holds, the event type read from the customer's MRR around the step and the ATL lifecycle tag set. The ledger cannot say what kind of expansion it was, so expansion_classification stays empty for your amendment records to fill. Same mapping input as generate_query, plus the ledger's currency; the dialect comes from the request or your warehouse, and unmapped fields are listed.

The readiness checks the standard states, as SQL over the datasets your mapping covers: CEL row identity, MRR continuity, unique event ids, the three ATL tags, customer identity both ways and freshness per dataset, one statement with one row per check. GASP has no warehouse access, so you run it and paste the rows back as results; the tool then reports pass or fail per check and per metric, each check naming the metrics whose formulas read what it covers. Same mapping input as generate_query.

The ranked fix list: every unmapped field and every failing check, ordered by Core metrics unlocked, then all metrics unlocked, with an effort class (small, medium, large) shown and used only as a tiebreak. A fix unlocks a metric when it is the last thing between that metric and covered-and-passing. Pass the results from generate_checks to rank data fixes beside mapping gaps.

Diagnose what could explain an observed metric movement. Walks the graph in reverse and returns ranked upstream candidates with full path and per-step edge classifications. A metric read only as a baseline (at period start, as MRR is in NRR) is listed as a component and the walk stops there. It reasons from the graph's structure and makes no numeric forecast.

Enumerate up to five forward edge chains from one metric or node to another, with the edge type and classification (metric_signal, structural, lifecycle, behavioral, assignment or generative) of each step.

Audit a metric set: one-hop upstream and downstream metrics missing from the set, plus metrics with no path to it. Run it before instrumenting a dashboard.