Founder Weekly Metrics Close: Definition Versions, Source Watermarks, and Late Corrections

On Monday, the report shows “143 users activated last week.” After a batch of offline events arrives on Wednesday, the number becomes 157, and revenue falls when refunds synchronize at the end of the month. If the weekly operating report always recalculates when someone opens the page, the founder cannot explain why the company hired staff, paused a channel, or adjusted its budget at the time. If the numbers are copied into a spreadsheet and never updated, known errors persist indefinitely. The purpose of closing is not to declare the data permanently correct. It is to freeze one generation of metric definitions and provably complete inputs, then preserve the before-and-after relationship through explicit corrections.

The AI Feature Evidence Scorecard determines which product evidence merits investment, while the Developer Launch Holdout Experiment determines whether promotion creates incremental impact. This article governs only the weekly management snapshot assembled from product, sales, and finance inputs. It does not interpret metric levels as causal conclusions or replace billing or accounting entries.

Freeze metricDictionary.v1 First

Publish an immutable founder.metricDictionary.v1 for every management metric: a stable metricId, business question, unit, population and exclusion criteria, event or table fields, deduplication identity, aggregation function, time zone, window boundaries, currency conversion version, owner, allowed lateness period, and materiality threshold. The query text must also bind the warehouse commit, execution image, and reference-data digest. Recording only the phrase “active users” is insufficient for recomputation.

schema: founder.metricDictionary.v1
dictionary: operating-core@12
metricId: weekly-activated-workspaces
unit: workspace
population: workspace.created_at < period.end
qualifyingEvent: onboarding.completed@3
identity: [workspace_id, onboarding_generation]
window: {timezone: UTC, weekStarts: MONDAY}
allowedLatenessHours: 36
materialCorrection: {absolute: 5, relativePct: 2}
queryArtifact: sha256:5c9...

The OpenTelemetry Metrics Data Model distinguishes the identity of a metric stream and defines temporality, start time, and data point time. Adopters must still lock the semantics they use and their SDK and collector versions. A counter restart, conversion of a cumulative value to delta, or label rename changes the result; a time series with the same name must not automatically be treated as the same business metric. The AI Usage Metering Idempotent Ledger handles idempotency and settlement for billable events. This weekly report may reference only its published watermark and must not duplicate a looser form of token deduplication.

Every source issues a sourceCheckpoint.v1 containing the source generation, maximum ingested position, covered occurred-time interval, extraction start and end times, schema digest, row count, and completeness status. CloudEvents id, source, and type can provide event identity material, but the specification does not define global business deduplication. Duplicates, divergent content under the same ID, and missing ordering guarantees must be counted separately in the source receipt. Event-Driven Architecture explains the delivery mechanism; this process accepts only checkpoints already sealed upstream and does not expand into streaming watermark algorithms.

Each Close Has Only One Acceptance Point

Represent each week as [start,end) instants with explicit RFC 3339 offsets. Do not write “the second week of July” and then depend on the viewer’s local time zone. A weeklyClose.v1 binds the period, dictionary digest, every source checkpoint, query artifacts, output-table digest, the denominator for each metric, exception list, and reviewer. The process is OPEN -> COLLECTING -> PRELIMINARY -> RECONCILING -> READY_TO_CLOSE -> CLOSED; an unknown source enters BLOCKED_SOURCE, while an unexplained material discrepancy enters EXCEPTION_REVIEW.

The only acceptance point is when the owner signs a weeklyCloseReceipt.v1 for the current close generation and advances READY_TO_CLOSE to CLOSED with CAS. The receipt must prove that every required source reached the specified watermark, the queries ran from fixed artifacts, cross-source invariants passed, and exceptions received explicit waivers. Successful dashboard rendering, completion of a scheduled job, or sharing a spreadsheet does not constitute closing. After close, every management decision references the closeId and metric value digest rather than a drifting dashboard URL. Versioned AI Gross-Margin Cost Attribution provides versioned revenue and COGS results; the weekly report references its generation instead of reallocating costs itself.

Late-arriving data must not rewrite a CLOSED generation in place. The system creates a weeklyCloseCorrection.v1 that binds the original close, discovery time, affected metrics, old values, new values, reason, supplemental checkpoint, and approval rules. Corrections below the materiality threshold can enter the next week’s cumulative notes. Corrections above the threshold, or those that alter a decision already made, enter CORRECTION_REVIEW. Once accepted, they generate a new close generation and mark the old version SUPERSEDED rather than deleting it. Reports display both as-reported and restated values so the team cannot present the latest value as though it had been known at the time.

Attack the Process with Misalignment, Duplication, and Manual Spreadsheet Edits

Test fixtures inject a 48-hour CRM delay, duplicate event delivery, different payloads under the same CloudEvent identity, a collector restart that makes a cumulative counter jump backward, a refund arriving after close, an exchange-rate table generation change, events at UTC boundaries, a regressing source checkpoint, a force-pushed query commit, and direct edits to an exported spreadsheet. Conflicts are expected to enter quarantine, while watermark regression and artifact mismatches must block acceptance. Rerunning the same generation must produce the same output digest.

Gates require 100% of core metrics to have an owner, unit, population, window, and query digest, and 100% of required sources to have rereadable checkpoints. Zero instances of divergent content under the same identity may be accepted, zero manual adjustments may remain unattributed, and reruns over the same inputs must produce matching digests 100% of the time. Differences in cross-source control totals must not exceed the preregistered 0.1%; anything above that threshold must be explained item by item. At least 95% of weekly reports must close within 48 hours after the period ends, material corrections must enter review within one business day after discovery, and no UNKNOWN value may be converted to 0.

Begin rollout by generating shadow closes for six consecutive weeks without changing the existing weekly meeting spreadsheet, comparing only values, latency, and exception buckets. Then make the new receipts the display source for two nonfinancial metrics. Switch the alias atomically by close generation, while the old queries and spreadsheets continue running during the rollback window. If a discrepancy cannot be reproduced, close latency exceeds the limit for two consecutive weeks, or a correction is lost, stop issuing new receipts and switch the display alias back to the previous generation; already sealed closes remain intact. Expand to high-impact metrics such as revenue and gross margin only after exercising one late-data correction and one dictionary upgrade.