Seventeen tabs. Each entry below states what the tab is, every element on it, how to read it, the formulas involved and the decisions it supports.
2.1 Mandate scorecard
The index: every line of the commercial mandate mapped to an owning metric
This tab turns the Chief Commercial Officer mandate into a scorecard. Each mandate line — own the end-to-end P&L, set pricing architecture, own billing and metering, build enterprise and partner GTM, establish the marketplace model, own cost and token economics, partner with the platform teams, build the leadership team — is given exactly one owning metric, a target, a current value, a trend and the tab that evidences it.
It exists so nothing in the remit is asserted without a number behind it, and so a reviewer can traverse from a claim to the evidence in one click.
What you see
- Coverage tiles
- How many mandate lines are on target, at risk, or off target this month.
- Mandate table
- Mandate line · owning metric · target · current · trend · evidencing tab (clickable).
- Status chips
- Green on target, amber watch, red off target — thresholds are the target column, not judgement.
How to read it
- Amber means inside 10% of target on the wrong side; red is beyond that. A line with no metric would be a gap in the design, so there are none.
- The trend arrow compares to the three-month average, not last month, to suppress single-month noise.
Decisions it supports
- Where to spend the next management cycle: pick the red line, click through, act on the exception table there.
- What to put on a board slide: this table is the one-page answer to 'is the commercial function delivering'.
2.2 P&L cockpit
Margin is made in the cost stack, not the rate card
The end-to-end profit and loss for the capacity and token businesses in one place: revenue by product line, the margin bridge from gross revenue to EBITDA, fleet and token utilization, and the depreciation drag that separates a healthy cash margin from a thin accounting one.
What you see
- Revenue (closed month)
- Total recognised revenue with month-on-month delta and a twelve-month sparkline.
- EBITDA margin
- Cash margin after operating cost, before depreciation and interest.
- Achieved $/GPU-hr (blended)
- All revenue ÷ all sold GPU-hours, including token revenue converted to a GPU-hour equivalent. This is the single most useful pricing number in the app.
- Fleet utilization
- Sold hours ÷ available hours across the fleet.
- Pre-tax margin
- After depreciation and interest — the number that services debt.
- Revenue by product line
- Stacked series across reserved capacity, tokens, endpoints, fine-tuning and marketplace.
- Margin bridge waterfall
- Revenue → cost to serve → gross margin → opex → EBITDA → depreciation → pre-tax.
- Fleet & token utilization chart
- The two utilization series plotted together; divergence is the story.
How to read it
- Compare achieved $/GPU-hr against $2.05. Above it, token multiplexing or premium endpoints are carrying the mix; below it, discounting or idle capacity is.
- If EBITDA margin is healthy but pre-tax margin is thin, the problem is capital intensity, not commercial execution — that pushes you to the Compute futures tab, not to pricing.
- A widening gap between fleet and token utilization means silicon is being held for capacity buyers who are not consuming; check the take-or-pay drawdown on Customers & contracts.
Formulas
| Achieved $/GPU-hr | total revenue ÷ (capacity GPU-hours + token GPU-hour equivalents) |
| Cost to serve | cash opex per GPU-hr ≈ $0.485 (power, cooling, network, storage, staff, platform) |
| Depreciation | ≈ $1.01/GPU-hr at 5-year straight line, GB300-class |
Decisions it supports
- Whether this month's margin move came from price, mix, utilization or cost — the bridge answers it directly.
- Whether to escalate a cost line to FinOps (the FinOps & capacity tab holds the joint sign-off).
2.3 Meter to cash
Metered is not billed, and billed is not collected
The order-to-cash funnel, from raw meter events through rating, invoicing and collection, with the drop at each step quantified. It exists because unbilled consumption is pure margin loss that never appears in a revenue chart — it is simply absent.
What you see
- Meter-to-cash yield
- Collected value ÷ metered value for the closed month. The headline efficiency of the whole billing chain.
- Rated ÷ metered
- The rating stage yield. Anything under 100% is either legitimate suppression or a defect.
- Unbilled usage
- Rated value sitting in no invoice, in dollars, with aging.
- Collected ÷ invoiced
- The cash conversion stage.
- Funnel chart
- Each stage as a bar, with the absolute and percentage drop between stages.
- Yield trend
- Twelve-month series for the composite yield.
- Unbilled aging table
- By customer and age bucket (0–30, 31–60, 61–90, 90+ days).
How to read it
- Read the funnel right to left when diagnosing: a collection problem is a credit problem, an invoicing problem is a process problem, a rating problem is a platform defect.
- Unbilled usage older than 60 days should be treated as at risk of becoming unbillable — many contracts have billing windows.
Formulas
| Composite yield | rated/metered × invoiced/rated × collected/invoiced |
| Unbilled aging | rated_line_item value with no invoice_id, bucketed by rating date |
Decisions it supports
- Which stage owns this month's leak, and therefore which team gets the action.
- Which customers to chase before the billing window closes.
2.4 Revenue assurance
Leakage is recoverable; perished capacity is not
The control layer. Recovering one to three percent of revenue leakage carries no incremental cost of goods, which makes these controls a direct, high-margin lever on EBITDA — arguably the highest-return work in the commercial function.
The tab is built around the daily automated three-way match (control C-01), a set of BLOCKING controls that halt billing closes, code releases or general-ledger postings when they fail, and a set of operational controls that close the softer leakage channels.
What you see
- Leakage rate (TTM)
- Leaked value ÷ rated revenue over twelve months. Target under 0.5%.
- Billing accuracy
- Share of rated lines that survive the match without adjustment. Target above 99.5%.
- Recovery rate
- Recovered ÷ identified leakage for the month. Target above 70%.
- SLA credit ratio
- Service-credit value as a share of invoiced revenue.
- DSO — enterprise
- Days sales outstanding on the enterprise book.
- Leakage by mode
- Where value is lost: mis-rating, missing meters, un-invoiced usage, credit notes, SLA credits.
- Identified vs recovered
- Twelve-month series; the gap is the write-off.
- Three-way match panel
- The C-01 backbone: the three legs matched, the tolerance on each, and the current state.
- BLOCKING controls table
- Control · what it blocks · mechanism · data source · formula/test · state.
- Operational leakage controls
- C-03, C-05, C-06 and siblings, with the no-incremental-COGS note.
- RA KPI targets
- Completeness >99.8%, billing accuracy >99.5%, recovery >70%, dispute rate <1%.
How to read it
- A BLOCKING control in a failed state means the close is halted by design — it is not a warning, it is a stop. Treat any failed blocking control as the top item of the day.
- The Data source and Formula columns are there so the control can be re-run by hand against the warehouse; a control you cannot recompute is a control you cannot audit.
- Identified-but-not-recovered leakage compounds: the older it is, the lower the recovery probability, which is why the recovery rate is measured monthly rather than cumulatively.
Formulas
| Three-way match | meter events ↔ rated line items ↔ invoiced lines, matched on usage window and resource ID, within tolerance |
| Leakage rate | leaked value ÷ rated revenue |
| Recovery rate | recovered value ÷ identified leakage, same period |
| Completeness | meter events landed ÷ meter events expected from fleet inventory |
Decisions it supports
- Whether the month can close (blocking controls) and whether the GL posting is safe.
- Which leakage mode to fund an engineering fix for — rank by TTM value, not by count of incidents.
- Whether SLA credits are a service problem or a commercial-terms problem; the incident-ID linkage settles it.
2.5 Customers & contracts
Renewals are won nine months before they expire
Concentration, contract value, take-or-pay drawdown and expiry timing in one view, so the desk opens renegotiation while it still has leverage rather than discovering a lapsed anchor contract at quarter end.
What you see
- TTM revenue
- Twelve-month revenue across the customer book.
- Top-1 and top-3 concentration
- Share of revenue from the largest and three largest accounts.
- Backlog
- Contracted-but-unconsumed value remaining.
- ACV up for renewal (12 mo)
- Annual contract value with an expiry inside the next twelve months.
- Revenue by customer
- Ranked bar chart.
- Take-or-pay drawdown
- Contracted hours versus consumed hours per customer — the unconsumed portion is billed regardless, and is a renewal risk.
- Contracted backlog
- Runoff of remaining contract value by month.
- Renewal timeline
- Contracts bucketed by expiry window with status chips (open, in negotiation, at risk, closed).
- Customer economics table
- Per customer: revenue, achieved rate, drawdown, expiry, action.
How to read it
- Low drawdown on a large contract is a warning, not a win: the customer is paying for hours it is not using and will negotiate hard at renewal. Start those conversations first.
- Top-1 concentration above roughly a third makes the whole P&L a single-counterparty story; that changes the risk framing on the Compute futures tab.
- The nine-month rule: any contract inside the nine-month window with no negotiation status is an exception.
Formulas
| Drawdown | consumed hours ÷ contracted hours |
| ACV up for renewal | sum of annualised contract value where expiry ≤ 12 months |
| Concentration | customer revenue ÷ total revenue, TTM |
Decisions it supports
- Renewal sequencing and the opening position for each negotiation.
- Where concentration risk needs a mitigating hedge or a new anchor.
2.6 Capacity ledger
Every installed GPU-hour is classified exactly once
The reconciliation from installed hours to billed hours with no unexplained residual. It exists because the difference between installed and sold is the largest source of silent margin loss on a depreciating fleet — the meter runs whether or not anyone is paying.
Six mutually exclusive, collectively exhaustive classes: pre-acceptance, faulted, productive, contracted headroom, leaked and perished.
What you see
- Monetisation
- Productive hours ÷ installed hours.
- Availability
- 1 − (pre-acceptance + faulted) ÷ installed.
- Leaked — recoverable
- Consumed but never billed. Recoverable, and it flows to Revenue assurance.
- Perished — foregone
- Idle and unsold. Not recoverable, ever. This is the number the futures hedge exists to address.
- Ledger waterfall
- Installed hours stepped down through each class to billed hours.
- Class table
- Hours, share of installed, dollar value at reference rate, and owner for each class.
- Invariant check
- The six classes sum to installed hours — displayed as a pass/fail, and unit-tested in the codebase.
How to read it
- Leaked and perished look similar in a chart and are opposite in economics. Leaked hours are a billing defect worth chasing; perished hours are gone and can only be prevented next month.
- Contracted headroom is not waste: it is capacity a take-or-pay customer has already paid for and chose not to use. It should not be resold without an overbooking policy.
- If the invariant fails, no other number on the tab is trustworthy.
Formulas
| Invariant | pre-acceptance + faulted + productive + headroom + leaked + perished = installed |
| Monetisation | productive ÷ installed |
| Perished value | perished hours × reference rate ($2.05/GPU-hr) |
Decisions it supports
- Whether the fleet problem is technical (faulted, pre-acceptance), commercial (perished) or systems (leaked).
- How much residual capacity the RL simulation should be allowed to price.
2.7 GTM & SKU mix
Sell certainty first, then monetize the remainder
Revenue and margin by SKU across the seven-segment portfolio — reserved capacity, token-as-a-service, private endpoints, fine-tuning, telecom edge inference, agent runtime, marketplace revenue share — sequenced into three waves, plus the granular initiative set for each segment.
What you see
- Committed share of revenue
- Take-or-pay revenue ÷ total. The target band is 60–75% before any merchant hour is priced.
- Wave-1 SKU revenue
- Revenue from the first-wave SKUs against the seven-SKU total.
- Blended gross margin
- Margin across the mix — the number that mix decisions move.
- Take-or-pay drawdown
- Fleet-level consumption against commitment.
- NRR / marketplace GMV
- Net revenue retention and marketplace gross merchandise value.
- Revenue by SKU
- Ranked bars with the wave each SKU belongs to.
- Segment coverage
- Contracted versus consumed by customer segment: captive, anchor labs, enterprise/BFSI, developers, government.
- Strategic initiatives
- Per segment: trends, use cases, sales motions, named-type target customers, partners and the ROI posture.
- SKU ROI table
- Gross margin band, capital intensity, payback and the primary risk per SKU.
How to read it
- Margin and capital intensity move in opposite directions across the portfolio: reserved capacity is 30–45% margin and very capital-hungry; agent runtime is 70%+ at almost no incremental capital but with speculative demand. A portfolio needs both ends.
- Committed share below 60% means the depreciation schedule is unfunded; above 75% means you are giving away the upside of a tight market.
- Coverage gaps by segment are the actual pipeline targets — the chart names them.
Formulas
| Committed share | take-or-pay revenue ÷ total revenue |
| Blended margin | Σ(SKU revenue × SKU margin) ÷ Σ(SKU revenue) |
| NRR | (starting ARR + expansion − contraction − churn) ÷ starting ARR |
Decisions it supports
- Which wave-2 SKU to fund next, given margin, capital intensity and payback.
- Which segments to over-index the sales motion against this quarter.
2.8 Pricing & packaging
The discount waterfall, not the price book, sets realized price
Price architecture by SKU and packaging model — reserved take-or-pay, per GPU-hour, per million tokens, per endpoint, per training job, outcome-based per resolved task, revenue share — with list, floor and realized prices, the list-to-realized waterfall, realization by segment, and the governance log of every price change.
What you see
- Realization tiles
- List value, contracted value, realized value and the erosion between them.
- Discount waterfall
- List → volume discount → commitment discount → non-standard concession → realized.
- Price realization by segment
- Realized ÷ list per segment; the outlier is where governance failed.
- Price book table
- SKU, packaging model, unit, list, floor, realized, margin at realized.
- Governance log
- Every price change: date, SKU, old, new, approver, rationale.
- Outcome vs metered crossover
- Where outcome-based pricing beats metered pricing for the same workload.
How to read it
- Non-standard concessions are the line to watch: the design target is under 3% of list. Volume and commitment discounts are earned; non-standard concessions are conceded.
- A floor price breach in the price book table is a hard exception — the floor is set at cost-to-serve plus the minimum acceptable contribution.
- Segment realization below the fleet average with no strategic rationale is a discipline problem, not a market problem.
Formulas
| Realized price | invoiced value ÷ billed units |
| Realization rate | realized ÷ list |
| Floor | cost to serve + minimum contribution margin |
Decisions it supports
- Whether to tighten the approval threshold on non-standard concessions.
- Which SKUs should move from metered to outcome-based pricing.
2.9 Billing platform (OSS/BSS)
Billing is an SLA-bound system, not a back office
The health of the order-to-cash platform: onboarding, entitlement, metering, rating, invoicing, collections and settlement, each with a service-level objective, plus disputes by root cause and credit-note volume. A metering or rating defect is a revenue defect, and it surfaces here days before it reaches the P&L.
What you see
- Stage health
- Each order-to-cash stage against its SLA, with current state.
- Platform SLOs
- Ingestion lag, rating accuracy, invoice-on-time rate, DSO, dispute rate, unbilled aging.
- Disputes by root cause
- Ranked: metering gap, rate-card mismatch, contract terms, service credit, customer error.
- Credit notes
- Volume and value, trended.
How to read it
- Ingestion lag is the leading indicator of everything else: if events land late, rating is late, invoicing slips, and DSO follows about six weeks later.
- Dispute root causes that are internal (metering gap, rate-card mismatch) are engineering backlog items; external ones are a collections conversation.
Formulas
| Invoice on time | invoices issued by contractual date ÷ invoices due |
| Rating accuracy | rated lines matching recomputation ÷ rated lines sampled |
| Dispute rate | disputed invoice value ÷ invoiced value |
Decisions it supports
- What goes on the platform engineering roadmap, ranked by revenue exposure rather than ticket count.
2.10 Marketplace & partners
Take rate only counts after partner settlement
Two-sided marketplace economics: gross merchandise value, take rate, net revenue, partner tiers and revenue-share terms, the settlement flow and its aging, and the cold-start and attach metrics that say whether the marketplace is actually two-sided yet.
What you see
- GMV
- Gross merchandise value transacted through the marketplace.
- Take rate
- Platform share of GMV, by tier.
- Net revenue
- What is recognised after partner settlement — the only marketplace number that belongs in the P&L.
- Partner tiers
- Tier, rev-share terms, partner count and GMV contribution.
- Settlement flow and aging
- Amounts owed to partners, by age.
- Attach and cold-start metrics
- Attach rate to core compute, supply-side and demand-side growth.
How to read it
- Quote net revenue, never GMV, in any P&L context. GMV is a scale metric for the marketplace team only.
- Settlement aging that stretches is a partner-retention risk long before it is a cash benefit.
- Cold start is only broken when both sides grow in the same period; one-sided growth reverts.
Formulas
| Net revenue | GMV × take rate − settlement adjustments |
| Attach rate | customers using ≥1 marketplace SKU ÷ core compute customers |
Decisions it supports
- Whether to invest in supply or demand next, and whether a tier's take rate is defensible.
2.11 FinOps & capacity
Cost per GPU-hour and per million tokens is the shared scoreboard
The cost-to-serve stack per GPU-hour and per million tokens, unit-cost efficiency against batching density, and commitment-versus-available capacity by region. This is the joint sign-off surface with AI Cloud Platform, Model Serving, Compute & Hardware, Data Center Infrastructure and Finance.
What you see
- Cash cost stack
- Power, cooling, network, storage, staff, platform — per GPU-hour, summing to about $0.485.
- Cost per million tokens
- The same stack expressed on the token unit, which moves with density.
- Unit cost vs batching density
- Cost per million tokens falls as density rises; the curve is the argument for multiplexing.
- Capacity by region
- Committed versus available, so commitments are never sold against capacity that does not exist.
- Joint sign-off panel
- Which partner function owns which cost line and what they have signed.
How to read it
- Power and cooling dominate the cash stack; platform and staff are the lines commercial decisions actually move.
- A region where committed exceeds available is an oversell — that is a stop, not a stretch target.
- Unit cost per token is only comparable across months at equal density; the chart is there so the comparison is made correctly.
Formulas
| Cost per GPU-hr | Σ cash cost lines ÷ available GPU-hours |
| Cost per M tokens | cost per GPU-hr ÷ (tokens per GPU-hr at density d) × 1e6 |
Decisions it supports
- Where the next capacity commitment can safely be sold.
- Which cost line to attack for the largest unit-economics gain.
2.12 Token economics
Above 21.3% traffic density, tokens beat renting the node
The multiplexing arbitrage made explicit. A node sold as reserved capacity earns the contracted rate no matter what runs on it. The same node serving tokens earns per million tokens, so its revenue scales with how densely the endpoint is loaded. Below a threshold density, renting wins; above it, tokens win by a wide margin.
With the worked node economics used here, the crossover sits at roughly 21.3% density: $16.80 of node cost against $78.84 of peak node revenue. At 60% density the same silicon earns about $5.91 per GPU-hour at roughly 76% gross margin, against roughly 33% sold as reserved capacity.
What you see
- Scenario sliders
- Token price per million, node cost, peak throughput and density — all tiles recompute live.
- Crossover chart
- Token gross margin and effective $/GPU-hr against density, with the reserved-capacity line drawn across it. The intersection is the crossover.
- Density ladder table
- Density step by step with revenue, cost, effective $/GPU-hr, margin and the decision (rent / serve tokens).
- Margin tiles
- Effective rate and margin at the current slider position versus the reserved benchmark.
How to read it
- Margin rises from roughly 29% at 20% density to above 75% at 60%+ density. The curve is steep in the middle, which means small changes in routed traffic have large margin consequences.
- The crossover is a floor for a decision, not a target. Serving tokens at 25% density technically beats renting, but with no safety margin against a demand dip.
- Density is not utilization. A fully utilized node can be running at low density if requests are small and poorly batched.
Formulas
| Crossover density | node cash cost ÷ node revenue at peak density ≈ 16.80 ÷ 78.84 ≈ 21.3% |
| Effective $/GPU-hr | (tokens served per hour ÷ 1e6) × price per million tokens ÷ GPUs in node |
| Token gross margin | 1 − (node cost ÷ node revenue at density d) |
Decisions it supports
- Which slice of the fleet should serve tokens at all, and at what minimum routed density.
- The floor price per million tokens that still clears the reserved-capacity opportunity cost.
2.13 Compute futures
Hedging converts a perishable asset into bankable cash flow
GPU capacity is perishable: an unsold hour is destroyed revenue, and the hardware depreciates over four to six years regardless. This tab models a 1,024-GPU cluster (scalable with the slider) across the $2.10 → $1.70 per GPU-hour price path, unhedged versus hedged with a futures overlay, and shows the effect on EBITDA and debt payback.
What you see
- Scenario sliders
- Utilization, cluster size, price-path start and end, hedge ratio and futures strike.
- Cluster capex
- Capital at the chosen cluster size, GB300-class, five-year depreciation.
- Sold GPU-hours per year
- Derived from cluster size and utilization.
- EBITDA at path start and end
- The unhedged sensitivity, with the hedged figure alongside.
- Payback at path end
- Years to recover capex, unhedged and hedged, with the spread.
- Hedge overlay tile
- Ratio of sold hours hedged and the strike.
- Sensitivity chart
- EBITDA and payback across the price path, unhedged versus hedged.
How to read it
- Shorting at $2.10 into a market that clears at $1.70 returns about $0.40 per hedged GPU-hour, which is what compresses the payback spread.
- The hedge does not raise the ceiling; it raises the floor. In a rising market the hedged line underperforms — that is the premium being paid for financing certainty.
- Payback beyond the depreciation life is the failure condition. Watch the point on the slider where that happens; that is the real risk boundary, and it is usually a utilization number, not a price number.
Formulas
| Annual revenue | GPUs × 8,760 × utilization × price |
| EBITDA | revenue − (sold hours × $0.485) |
| Hedge P&L | hedged hours × (strike − spot) |
| Payback | capex ÷ EBITDA |
Decisions it supports
- What hedge ratio to run against the merchant book, and at what strike.
- Whether a financing structure survives the downside price path.
2.14 RL simulation
Pricing residual capacity is sequential, not a rate card
An agent-based environment for the non-committed slice of the fleet. Four customer cohorts each have their own elasticity, willingness to pay and patience; demand that is priced out defers and comes back, so today's discount destroys tomorrow's price. Reward is revenue-weighted utilization net of cash operating cost and a perishment penalty. Take-or-pay hours are a hard constraint served before the agent acts.
Four policies are compared: the static price book, greedy fill, a threshold heuristic, and an epsilon-greedy contextual bandit trained in the browser.
What you see
- Environment controls
- Cohort mix, elasticity, patience, demand volatility, episode length, exploration rate.
- Policy comparison
- Revenue-weighted utilization, realized rate, perished hours and reward per policy.
- Learning curve
- Bandit reward across training episodes.
- Uplift tiles
- Each policy against the static price book baseline.
- Validation panel
- Hold-out backtests, invariant pass/fail checks, and a parameter-sensitivity tornado chart.
How to read it
- Greedy fill almost always wins on utilization and loses on realized rate — that is the trap the reward function is designed to expose.
- Never read the uplift without the validation panel. A result that fails an invariant is not a small error, it is a broken model.
- The tornado chart ranks which assumption the conclusion depends on. If the top bar is an assumption you cannot observe in production, the result is not yet decision-grade.
Formulas
| Revenue-weighted utilization | revenue ÷ (capacity hours × reference rate) |
| Reward | revenue − cash opex − perishment penalty |
| Uplift | (policy reward − static reward) ÷ static reward |
Decisions it supports
- Whether to pilot a dynamic pricing policy on the residual book, and with what guardrails.
- Which parameters need real-world instrumentation before the policy is trusted with revenue.
2.15 Commercial org
A P&L this size is owned by a team, not a leader
The organisation scorecard: five functions — billing platform, enterprise sales, marketplace, FinOps and revenue assurance, customer success — each with an owner, headcount, objectives, succession depth and talent metrics. Org capability is the constraint on every other tab's plan.
What you see
- Function cards
- Owner, headcount, current objectives and status per function.
- Succession depth
- Ready-now and ready-later cover for each leadership seat.
- Talent metrics
- Open roles, time to fill, regretted attrition.
How to read it
- A function with no ready-now successor is a single point of failure on a revenue-critical process; that is a risk to state alongside financial risk, not below it.
- Objectives here should map one-to-one to mandate lines on the scorecard tab. Where they do not, either the objective or the mandate line is wrong.
Decisions it supports
- Hiring sequence and where to build bench strength first.
2.16 Why Reliance / Why Ilan
The mandate, matched requirement by requirement
The case in two halves: three reasons this token and capacity P&L is worth building at Reliance specifically, three reasons the operator's record matches the mandate, then a requirement-by-requirement evidence map against the role criteria and a first-90-days plan.
What you see
- Why Reliance
- Three bullets on captive demand, integrated infrastructure and the sovereign-scale opportunity.
- Why the operator
- Three bullets with the record behind each.
- Evidence map
- Each 'what you'll bring' criterion against the artefact in this app that demonstrates it.
- First 90 days
- Sequenced plan with what is closed by day 30, 60 and 90.
How to read it
- Every row of the evidence map links to a live tab or document. The claim and the artefact are never separated.
Decisions it supports
- It is the closing argument of the whole app — read it after the cockpit, not before.
2.17 Glossary
One definition per term, used everywhere in the app
Every ledger class, invariant and KPI formula defined once, searchable and filterable by category. The same strings power the ⓘ tooltips throughout the cockpit, so a definition can never drift from its tooltip.
What you see
- Search box
- Matches term, definition, formula and note.
- Category filters
- Ledger, funnel, pricing, margin, contract, platform, simulation and so on.
- Entry cards
- Term, definition, formula in monospace, and any caveat.
How to read it
- If two people disagree about a number, settle the definition here before arguing about the value.
Decisions it supports
- It is the reference layer; it supports every other decision rather than making one of its own.