GitLab 10-K corpus: seven-year income statement and operating metrics

[briansrls]

Summary

Models GitLab's complete post-IPO financial history (FY2020–FY2026) from SEC filings, grounding the company's income statement and operating metrics in XBRL facts. Establishes the foundation for SCM economics analysis by capturing revenue, cost of revenue, operating expenses (broken into three components), operating income/loss, net income/loss, and key operating metrics (ARR-threshold customer counts, dollar-based net retention, registered users, purchase commitments).

Key changes

• extdeps/sec/issuer/gitlab_facts.dag — Added seven years of income statement facts (FY2020–FY2026) with proper citations to each filing's accession number and period. Introduced FiledSignedMonetaryFact for credit-balance elements (operating income/loss, net income/loss). Added operating metrics facts (ARR customer counts, DBNRR, registered users, hosting commitments). Updated provenance notes with detailed filing authority and cross-footing guarantees.

• extdeps/sec/facts.dag — Refactored FiledFactCitation to use a closed FiledPeriod sum type (FiledDuration for flows, FiledInstant for balance/commitment amounts) instead of optional start/end fields. Added FiledSignedMonetaryFact type and signed_usd_negative() constructor for negative filed values. Added filed_signed_value() accessor.

• extdeps/sec/operating_metrics.dag (new) — Defined shapes for issuer-disclosed KPIs: DollarBasedNetRetentionRow, ArrThresholdCustomerCountRow, RegisteredUserCountRow. Captures GitLab's SaaS metrics with proper rate semantics (floor vs. exact).

• extdeps/pricing/gitlab_subscription.dag (new) — Modeled GitLab's three-tier subscription pricing (Free, Premium, Ultimate) with per-seat-month billing and Duo Credits bundling. Cites the live pricing page as authority.

• gunbc/econ/free_tier_serving.dag (new) — Bottom-up free-tier serving cost floor: derives infrastructure box count from per-user storage/egress envelope against Hetzner dedicated server pricing. Includes top-down average serving cost per registered user (filed cost of revenue ÷ registered user floor).

• test/claim/gitlab_10k_income_series_witness_test.dag (new) — Comprehensive witness suite verifying all seven years cross-foot exactly (GrossProfit = Revenue − CostOfRevenue; OperatingExpenses = three components; OperatingIncomeLoss = GrossProfit − OperatingExpenses). Witnesses revenue growth, S&M share decline, gross margin band stability, and operating loss convergence.

• test/claim/free_tier_serving_witness_test.dag (new) — Witnesses for free-tier serving floor derivation and average serving cost bounds.

• docs/plans/dag-scm-design.md (new) — Design seed for node-grain source control: thesis that merges/conflicts happen at node identity (not text grain), architecture sketch (content-addressed store, keyed diff, visibility grants, publication ladder, CI-as-realization), and roadmap integration.

• gunbc/roadmap_authority.dag — Added SCM roadmap section (operator-directed 2026-07-25).

• extdeps/sec/us_gaap.dag — Added GAAP element definitions for operating expense components and purchase commitments.

• Existing facts files (chemed_facts.dag, rollins_facts.dag) — Updated to use new FiledPeriod closed sum type.

Notable implementation details

• Period modeling as closed sum — FiledPeriod is a discriminated union, not optional fields, so a half-specified period is unwritable (correctness by construction per CLAUDE.md §1).

• Signed values for losses — FiledSignedMonetaryFact

https://claude.ai/code/session_01XddFQprkpseK3EsQDkUbRG

[briansrls]

Management review at e5279eb + the entity-modeling ruling the operator asked to flesh out.

What verifies well: FiledPeriod as a closed sum is the right §5 construction (a half-specified period is unwritable, not validated); FiledSignedMonetaryFact + signed_usd_negative model losses as typed negatives instead of sign-in-prose; the seven-year cross-footing witnesses assert the accounting identities exactly (GrossProfit = Revenue − CoR; OpEx = three components; OperatingIncomeLoss = GP − OpEx) plus honest trend witnesses; the free-tier serving floor grounds on the cited Hetzner price rows + RegisteredUserCountRow + std.measure, not hand numbers; chemed/rollins migrated to the new sum in the same PR (no dual representation left behind).

One finding: FiledFactCitation? — the optional citation means an uncited filed fact is representable. For SEC facts the citation IS the grounding; an Absent arm is a fail-open invitation. Make it required, or if migration needs the gap, a typed UncitedLegacy{reason} arm that's counted — never a bare ?.

The entity question (operator nit, adjudicated): the pieces already exist — extdeps/vendor/gitlab.dag (Vendor { legal_name: "GitLab Inc." }) and extdeps/sec/issuer/gitlab.dag binding that entity to its typed Cik. What's missing is the edges: gitlab_facts.dag carries its CIK only inside a URL string and imports neither row; the new pricing/gitlab_subscription.dag doesn't reference the entity at all. Today the only thing correlating the two fact families is the filename prefix — exactly the operator's discomfort.

The rule to land with this PR: folder = which upstream authority produced the facts; typed edge = which entity the facts are about. Subject and source are orthogonal axes, and filenames encode neither. Concretely: (a) gitlab_subscription.dag gains a subject edge to extdeps.vendor.gitlab.gitlab (its ExternalAuthority stays the pricing page — source unchanged, subject now typed); (b) the facts file threads the issuer row (or FiledFactCitation gains an issuer field) so the CIK-in-URL prose stops being the identity carrier.

Flag, not for this PR: GitLab is the tree's first two-domain entity, and it exposes that Vendor<Securities> puts the domain parameter on the wrong node — one GitLab Inc. can't be Vendor<Securities> and Vendor<Saas> without forking the entity. The parameter belongs on the relationship rows (each fact family declares its domain), with the entity row un-parameterized. That's a ~14-file migration touching all vendor consumers — file it on the grounding-inventory lane with this PR as its discriminating receipt, don't absorb it here.

The SCM design seed + roadmap section are operator-directed and read as a seed (no code claims); no adjudication needed. CI green + the two edge additions + the citation-required fix and this is merge-shaped.

---

Generated by Claude Code

[briansrls]

The regen red, explained + the fix that dissolves it without a regen run.

Why regen failed while heal passed: they verify disjoint generator outputs. regen proves the emitted-Rust seed fixed point — fresh emit of the seed closure vs the committed src/v1 .rs, byte-identical. heal_generated_artifacts covers the generated-artifact registry (ci.yml, ROADMAP.md, …), all of which this branch already carries regenerated. This PR edited seed-emitted dag/std/measure.dag (three new phantom markers PerStoredUnitMonth/PerTransferredUnit/PerMillionRequests + aliases + accessors) without regenerating the seed — the job log's diff shows exactly those symbols present in fresh emit and absent from the committed seed. Both jobs told the truth about different artifact sets.

Don't fix it by regenerating — fix it by relocating. This morning's management ruling (census lane) named the MoneyRate<P> phantom family the specimen defect (structureless phantoms, hand accessor pairs, no derivable conversions), with the directive to this PR: consume the current shape as-is; don't fork ahead. Adding three new phantom arms in std grows the family the Rate-framework item is queued to dissolve — every new arm is another consumer to migrate later. And MoneyRate<P> is generic: the markers don't need to live in std at all. Declare the three markers + aliases + accessors in the pricing layer (extdeps.pricing.object_storage or a sibling pricing-units module). That single move: (a) leaves dag/std/measure.dag untouched, so the regen divergence vanishes with no seed regeneration; (b) stops the anemic family growing in the framework layer; (c) parks the new units where the Rate-framework consumer sweep will collect them with the rest.

Keep the byte-basis insight exactly as written — the storage_billing_unit_note's refusal to bake a byte basis into the unit (AWS "GB-Mo" vs GCS "gibibyte hour", the 7.4% trap) is genuinely good modeling and survives unchanged as the per-row declared basis in object_storage. It's the phantom location, not the reasoning, that moves.

Also still open from the earlier review: the FiledFactCitation? optional-citation arm, the two entity edges (pricing → extdeps.vendor.gitlab, facts → the issuer row), and the body describing the Atlassian additions now in the diff.

---

Generated by Claude Code

[briansrls]

CI red on ci — failing on the base branch too, not from this PR

ci failed on 2e2b231 (run 30161916870) at batch 4:

✗ infer_semantics_witness_keystone_holds (src/v2/test/claim/infer_semantics_witness_test.dag)
  infer_semantics_witness.rs:628 assertion `left == right` failed
    left: 0   right: 1
  in invalid_slice_returns_compiler_error_type

The witness asserts that slicing a List<Int> yields exactly one "slice is only supported" diagnostic; it now yields zero.

Attribution, proven by execution rather than inferred. I built and ran the same witness from a clean worktree at origin/main (25873a3) with none of this branch's changes:

$ git worktree add <tmp> origin/main && cargo build --bin infer_semantics_witness && ./infer_semantics_witness
infer_semantics_witness: invalid_slice_returns_compiler_error_type panicked

Main is red on this witness on its own. Corroborating: this branch's only change under src/v1/stage0/src/ is the regenerated std_measure.rs (+36 lines of money-rate carriers); git diff origin/main HEAD -- src/v1/stage0/src/v1_compiler_infer_access.rs src/v1/stage0/src/bin/infer_semantics_witness.rs is empty — both the tested function and the test are byte-identical to main. The slice path was last touched on main by bb4347d (#7196, the Range-vs-usize seed-emitter trio).

Not fixing it here. Whether List slicing is now intentionally supported (update the witness) or the diagnostic was lost (restore it) is the #7196 lane's call, not something to guess at from an unrelated PR. Re-running once main recovers.

Separate observation from the same run, flagged as possibly partly mine: FLOOR-BATCH-OVER-BUDGET batch=4 wall_ms=551945 budget_ms=420000. This PR adds five witness entries to the discovery corpus, so some of that wall is mine; the budget row is a refusal-not-a-widen by design, so if it persists after main goes green I'll price my witnesses' contribution and either scope them or bring a receipt rather than ask for the budget to be raised.

This branch's own state is green by local execution at 2e2b231: regen_stage0 --verify → regen_divergence_count=0; generated_artifact_drift_witnesses, non_fold_residue_no_unrostered_or_stale, and all five SCM/econ witnesses PASS.

---

Generated by Claude Code

[briansrls]

Review items addressed — dd13596

1. std/measure.dag relocation — done, seed now untouched

Accepted without reservation; the argument that decided it is the one I should have applied myself: these markers are what clouds bill on, not universal-framework vocabulary, and the generics-instantiate-downstream point means nothing was bought by putting them in std.

• New extdeps/pricing/billing_units.dag carries PerStoredUnitMonth / PerTransferredUnit / PerMillionRequests, the three MoneyRate<P> aliases, and the storage_billing_unit_note. MoneyRate<P> itself stays in std.measure — the universal carrier is not the vendor's meter.
• dag/std/measure.dag and src/v1/stage0/src/std_measure.rs reverted to origin/main content. Receipt: git diff origin/main -- src/v1/ dag/std/ is empty. The PR touches zero seed files.
• The three money_per_*_micros wrappers deleted — byte-for-byte hollow aliases of money_rate_micros<P>. Both consumers now call it directly. The new module carries a note saying why no accessors are declared there, so the next author doesn't re-add them.

The seed-coupling argument was self-demonstrating: the +36 std_measure.rs lines were exactly what redded this branch's regen fixed-point gate earlier today.

2. IssuerCatalogRow.legal_name — not a duplicate, a fidelity gap

Investigating the nit turned it into a real finding. Measured against the EDGAR submissions API, the name of record differs from the company's own legal name for every issuer in the corpus:

issuer	EDGAR name of record	vendor legal name
GitLab	Gitlab Inc.	GitLab Inc.
Microsoft	MICROSOFT CORP	Microsoft Corporation
Atlassian	Atlassian Corp	Atlassian Corporation
Rollins	ROLLINS INC	Rollins, Inc.
Chemed	CHEMED CORP	Chemed Corporation

The field held the company form in all five rows — so it was a duplicate of vendor.legal_name and not the cited fact its position implied. Annotating it as "EDGAR's name of record" would have made the note a lie. Renamed to registrant_name, repopulated with EDGAR's actual strings from a live pull, and annotated: the registrant name is what EDGAR company/full-text search matches on (the lookup key for the filings), while the vendor edge carries the company's own legal name. Deriving either from the other would fabricate a string neither authority publishes.

3. Timing receipt (the criterion still owed)

Measured locally on this branch, one claim_batch invocation per entry:

keystone	witness eval	claim families	resolve (cold, standalone)
gitlab_10k_income_series_witness	11 ms	24	19.8 s
scm_provider_matrix_witness	9 ms	13	18.9 s
scm_issuer_corpus_witness	8 ms	15	20.3 s
scm_agentic_stress_witness	5 ms	11	20.2 s
free_tier_serving_witness	2 ms	11	20.2 s
scm_serving_model_witness	2 ms	11	18.3 s

37 ms of witness eval across all six — three orders of magnitude under the 5 s fast-lane rule, so all six are per-PR fixture-grain by measurement, not by assertion. Nothing here wants the falsifier cadence.

Stated plainly because it is the honest reading of the same table: the standalone resolve is ~19 s per entry and dwarfs eval. That is a closure-assembly cost, not witness work, and it is shared in the floor (the failing run's own receipt reads floor resolves: 1 entry resolve(s), 2439ms) — but it is the axis my six entries actually load, so it is where any batch-4 contribution of mine lives. If the over-budget signal survives main going green, that is the number I will price and scope against, not the eval column.

Verification

All green by execution at dd13596: six SCM/econ keystones + econ_wedge + both sec_edgar witnesses PASS; regen_stage0 --verify → regen_divergence_count=0; generated-artifact gate clean.

CI remains blocked on the pre-existing main red (invalid_slice_returns_compiler_error_type, base-branch control in the previous comment) — unblocked the moment the #7196 fix lands on main.

---

Generated by Claude Code