Per-tenant telemetry is the seam between Groundwork's dashboard and its bill.

The problem

Groundwork can only make a clean dashboard promise if each tenant has its own measurement record. The same rule applies to billing. If the dashboard says a tenant used a capability, and the invoice charges for that capability, both surfaces need to read the same underlying signal.

Without that per-tenant record, two bad outcomes follow:

• the dashboard becomes narrative instead of evidence;
• the invoice becomes a separate interpretation of reality.

That is the exact trust break the system is supposed to prevent.

What the signal needs to include

The useful raw signal is not one number. It is a tenant-scoped record of:

• connector and MCP usage;
• which skills and capabilities are actually deployed;
• skills-factory output that touched that tenant;
• effectiveness and performance measurements;
• the specific metered paths that should ever influence billing.

The key point is scope. Each tenant's telemetry has to stay isolated from every other tenant's telemetry. The dashboard can aggregate within a tenant. It cannot leak across them.

Why this matters for billing

Groundwork's clean billing model already draws a hard line: most of the substrate does not spend Rarefied Earth's API at all, so most of it should not meter like compute. The billing model only works if the measured layer is narrow and explicit.

You bill for a tier, for add-ons that were enabled, and for metered usage only on the paths that spend RE-owned resources. Connector snapshot reads make zero model calls on Rarefied Earth's account. Treating "module switched on" as if it were spend invents a charge the meter cannot defend.

That means per-tenant telemetry is not "track everything and price later." It is the opposite. It is the mechanism that proves:

• what was merely available,
• what was actually used,
• what spent RE-owned resources,
• and what should never become a charge.

If the signal is vague, the bill is vague. If the signal is tenant-scoped and typed, the bill can be explained line by line. The design constraint is stronger still: every charge should join to a dashboard fact, and every metered fact should point at a meter record. A charge with no dashboard counterpart is a trust failure.

The dashboard implication

The value dashboard and the invoice should read from the same record, but they do not need to say the same thing.

The dashboard answers:

• what your substrate is doing;
• which capabilities are active;
• where usage is trending;
• where performance or effectiveness is improving or degrading.

The invoice answers:

• which tier is active;
• which add-ons were enabled;
• which metered path actually incurred cost.

The shared discipline is that neither surface should invent a number the other cannot trace. Freshness reads can stay free. Paid analysis passes, when they exist, are scheduled writes gated by a cost meter inside the refresh runner. A page refresh must never trigger spend.

What Rarefied Earth has already learned

RE's own ops stack already has the raw ingredients for this:

• local usage rollups,
• module metrics,
• connector-side request surfaces and dark per-token request ceilings,
• a cost meter that can count analysis spend per tenant,
• billing design that separates subscription, add-ons, and metered usage.

What remains aspirational is the clean per-tenant join that strangers can trust on the product surface. The article should say that plainly. The architecture direction is real. The finished tenant-visible dashboard-to-billing loop is not yet live. Dogfood on Rarefied Earth's own tenant can use RE-local sources without pretending the public Coming tile is live analysis for every customer.

The boundary to keep

This work stays gated on tenant isolation. A telemetry system that makes the dashboard smarter but weakens tenant separation is a regression, not progress. The first acceptable version has to be boring on this point:

• one tenant's data stays one tenant's data;
• billing reads only the paths explicitly allowed to meter;
• operator analytics and client analytics stay distinguishable;
• rate-limit and safety ceilings are not confused with an exact billing meter.

Request-count ceilings protect the connector. They are not a substitute for a tenant-scoped usage ledger that dashboard and invoice can both cite.

The product claim worth making

The honest claim is not "Groundwork already has full per-tenant usage billing." It does not.

The honest claim is narrower and stronger: Groundwork is being designed so the dashboard and the invoice can read the same tenant-scoped signal, with isolation and pricing boundaries explicit from the start. That is the part most systems try to bolt on later, after the trust problem already exists.

Claims verified (2026-08-07 audit)

• Dashboard and billing design sources still support the same-signal framing (northstar §6; client-analysis design §1; billing model § dashboard/invoice constraint).
• Tenant isolation remains load-bearing for any telemetry layer (northstar N5 / adversarial S3). RE-200 (hosted connector) is Done; isolation is ongoing discipline, not a wait-for-RE-200 gate.
• Tenant-facing value dashboard remains aspirational, not live (northstar).
• Metered analysis, when shipped, stays behind an in-loop cost meter; page load must not spend.