CircleCI

totals over every repository's `reader.listRuns`, with duration read off each run's start and completion. THE ONE VALUE THAT IS NOT AN AGGREGATE IS CREDITS, and it is derived rather than zeroed or omitted: canon states the resource class (packages/compiler/src/files.ts writes `resource_class: medium` under a docker executor, and CircleCI's own default for a docker executor that declares none is medium too), and 10 credits/minute is CircleCI's published rate for docker/medium - so credits are whole minutes of job wall time at the vendor's list price, the same pin-scoped price-table shape renderer-anthropic and renderer-openai already use for token cost. `0` would be false and the field is required and not nullable. TRENDS ARE RELATIVE CHANGE against the same-length window immediately before, one rule for all nine floats because the document defines none; this universe's canon is exactly 90 days, so every trend on the default `last-90-days` window is 0 for want of a baseline and a caller asking for `last-7-days` gets real movement - conformance asserts both halves so the zeros read as arithmetic rather than as a stub. `all_projects` stays unfiltered when `project-names` narrows the rows

hello-15's TestCase/TestResult made this derivable and the derivation is CircleCI's own published definition, quoted: a flaky test is one that PASSED AND FAILED IN THE SAME COMMIT. The nightly is what makes it visible - this universe has main-line commits on 41 of its 90 days, so on 49 nights the schedule recompiles the sha it compiled the night before, which is the situation a flake shows up in and the reason real orgs find theirs in the nightly. Nothing is labelled flaky in canon: `flakiness` is a per-run rate the generator rolls against, and this row derives the OUTCOME from the results, exactly as the coherence suite does. `file` is null because canon states none (DECISIONS 2026-09-06 judgment 3), `source` is `junit` because canon states the report IS JUnit XML - ARTIFACT_MIME serves it as application/xml and JUNIT_BYTES_PER_CASE derives its size from the case count

the workflow's runs themselves, newest first, off `reader.listRuns`. Every `id` is the renderer's own `workflowId`, so conformance follows it to `GET /workflow/{id}` and asserts the two surfaces agree about the run (invariant #5). `branch` is the branch its pipeline was built on - the same derivation `GET /pipeline` prints, never a second copy. `is_approval` is false on every run because an approval is a MANUAL HOLD this canon has no entity for, the same fact `shapeWorkflowJob` states by emitting `type: build` on every job. `start-date`/`end-date` bound the window directly and an `end-date` without a `start-date` is refused, because the document says one must accompany the other

the same aggregates for one workflow, plus the trends against the preceding window and the project's full workflow list. Conformance asserts field-by-field that this row and the `/workflows` list carry the SAME numbers for the same workflow - two surfaces over one derivation, not two derivations. `completed_runs` equals `total_runs` and that is a fact about this canon rather than a field copied from its neighbour: every canonical WorkflowRun carries a completion instant and a terminal conclusion. This operation declares no `reporting-window`, so it reports on the document's own 90-day default

the same aggregates one level down: the project, each of its Workflows, and each (Workflow, branch) pair, over `reader.listRuns` and `reader.runJobs` with the branch taken from the renderer's own pipeline model. Conformance asserts the three levels RECONCILE - the workflow rows sum to the project's runs and so do the (workflow, branch) rows - which is what makes this a view of one fact rather than three. `all_branches` and `all_workflows` stay UNFILTERED when `branches`/`workflow-names` narrow the rows, because they are the lists the filters are chosen from. THE SLUG SITS BEHIND A LITERAL here, so the escaped-slug rewrite counts its two separators from `/api/v2/insights/pages/` rather than from `/api/v2/insights/`; counting from the shorter prefix spends one separator on the `/` after `pages` and 404s the escaped spelling, and both spellings are asserted over real HTTP

hello-15's PolicyDecision. The 2026-09-05 reason was that `a decision log entry records a pipeline being EVALUATED against a policy, and this universe has published no policy for anything to be evaluated against` - the canon now publishes the bundle AND logs 107 decisions against it, and A VIOLATION IS EVALUATED RATHER THAN DRAWN: the generator checks each enabled policy's rule against the config document the run was compiled from, so a reader who fetches the bundle, reads the Rego and re-evaluates it against the served config gets the served decision back. NO DECISION IS A HARD_FAIL and that is a fact rather than a gap - a hard fail blocks the pipeline and every pipeline here ran (DECISIONS 2026-09-06 judgment 6), asserted in both suites so a later wave does not read it as an oversight

founder re-ruling 2026-09-07: the bundle a decision was evaluated AGAINST, which is the policies that were ENABLED when it was made - strictly shorter than the whole bundle `.../policy-bundle` serves, because one policy is written and never enabled. Serving the two identically would make `enabled_rules` and the bundle one fact served twice, which is the thing the canon was shaped to avoid

hello-15's ConfigPolicy. The 2026-09-05 reason was that `Policy.content` is REGO SOURCE TEXT and `composing a policy document inside a renderer is exactly the invent-at-render-time the judging bar forbids` - so the Rego is composed in the COMPILER from the rule canon carries and the words the theme supplies, the same split the .circleci YAML lives under, and `config_policy.content_sha512` is the hash of exactly those bytes. A DISABLED POLICY IS STILL IN THE BUNDLE, which is what makes a decision's `enabled_rules` strictly shorter than this map rather than the same fact served twice

the same key addressed by either fingerprint. CircleCI reaches one key through this ONE path parameter by md5 OR sha256, so the reader resolves both through a single accessor - splitting them would let the two addressings drift

the same derivation addressed by name, asserted byte-identical to the row the list prints so a client cannot see two different values for one variable (founder ruling 2026-09-05)

one row per canonical Component this repository has really shipped: `reader.listDeployments` gives the rollouts, `reader.getCommitById` gives each one's commit, and the commit names the Component it changed - so `name` is `reader.componentSlug` of that id, the same slug renderer-github prints inside every changed file's path. `release_count` is the number of those deployments, which makes it the length of the /versions list by construction rather than by coincidence. `labels` is an honest empty (canon labels nothing here) and `org-id` and `page-size` are both declared REQUIRED, so a request without either is not one this operation accepts

one version per canonical Deployment of that component. `name` is the release TAG when the deployment shipped one (`reader.listReleases`; production deployments carry `ref = tag`) and the deployed commit's short sha otherwise - 16 of this universe's 19 deployments are staging rollouts whose `ref` is the default branch, and publishing `main` as a version name would give every one of them the same name. `is_live` is the newest SUCCEEDED deployment per environment, so a failed or still-queued rollout is in the list and is not live. FOUR FIELDS ARE DELIBERATELY ABSENT rather than filled: `namespace` (canon models no orchestrator) and `pipeline_id`/`workflow_id`/`job_id`/`job_number` - canon says a deployment is caused by a MERGE or a RELEASE, never by a run (generateDeployments), so naming the release-workflow run that happens to share the commit would assert a causal link this universe does not contain. Every property of the schema is optional, so absence is the document's own way of saying so. The operation declares NO page-token and NO page-size, so `next_page_token` is always null: issuing one would name a parameter the operation cannot accept

the same derivation addressed by id, asserted byte-identical to the row the list prints. A well-formed uuid naming no environment answers the shared entity 404; an id that is not a uuid answers the operation's own 400, the same split the context and schedule families already make on this host

the founder ruled this row and eighteen siblings on 2026-09-05, re-ruling B2.1's proposed empty: data is the product, so fulfil the contract. SERVED — and `derive` rather than `generate` is the accurate label, because the response is computed from artifact rows that already exist: one context per distinct `deployment.environment`, created at the earliest canonical deployment to it. No new canon and no new words — `staging` and `production` are structural canon strings, not themed prose

one variable per row of the canonical VENDOR_CATALOG - the third-party credentials a deploy job carries, named from vendor names the theme baked in at compile time, so no real company is named and no word is authored in the renderer. THE OPERATION PUBLISHES NO VALUES AT ALL: `env_var_list` declares variable/created_at/updated_at/context_id and nothing else, which is CircleCI's own posture on context credentials (founder ruling 2026-09-05)

hello-15's IdentityGroup, and the canon answers the objection this row was refused for. The 2026-09-05 reason was that mapping a Team onto an SSO group `would assert an SSO configuration nobody made`; hello-15 MAKES the configuration (IdentityProviderConfig - a protocol, a date and an administrator) and derives four groups from access facts rather than from team membership. Both canon suites assert no group has exactly a team's membership and that at least one crosses team boundaries, so the two entities stay distinct

hello-15's OidcClaimConfiguration. The org-scoped row is the one with no project, which is what makes it distinguishable from the project override beside it. `ttl` is formatted into Go's duration grammar because the document types it as a STRING (`JSONDuration`) rather than a number of seconds

one definition per canonical `Workflow` that really ran - ci, lint, release, the same theme-free keys renderer-github serves as the workflow identity on the same runs, in the artifact since hello-2. `description` is ABSENT because every property of `pipelineDefinition` is optional and canon states no prose about a workflow; `repo.external_id` is absent because it is the VCS's own repository id and this host mints none, so emitting one would hand back a value that resolves nowhere (invariant #5). `config_source.file_path` is .circleci/{key}.yml: the directory and extension are CircleCI's own grammar and the only variable part is the canonical key - the canonical `Workflow.path` is NOT reused, because it is a GitHub Actions path and printing it as the file CircleCI reads would state something false about both hosts (founder ruling 2026-09-05)

hello-15's WorkflowSchedule. The 2026-09-05 reason was exact and it is the reason this row can be served now: `a schedule served here would promise a nightly pipeline that GET /pipeline does not contain, and the first caller to check the two against each other would find it out`. So the canon did not add a schedule ROW, it added ~87 scheduled WorkflowRuns with their own jobs, logs, uploads and outcomes - a schedule is not a row, it is the runs it produced. The pipelines are there to be checked against, and `pinned-cross-category`/`ci-parity` do check. Name and description are canon prose the theme baked at compile time, so the second half of the old reason (`prose canon does not carry`) is answered too

one trigger per DISTINCT event the canon records that workflow's runs really being started by. A trigger is a claim that pipelines get created when something happens, so a pull-request trigger on a workflow only ever run by pushes would promise pipelines GET /pipeline cannot show - the trigger list is therefore derived from `WorkflowRun.event` rather than from CircleCI's enum. `event_preset` maps the canon's two events onto the two presets the document says every provider supports (all-pushes, only-build-prs); `disabled` is read off `Workflow.state` (founder ruling 2026-09-05)

the project's outbound build webhook, delivering to the org's own release-bot receiver - canon's `ReceiverSlot` is a CLOSED canonical union whose words are canon's, and the URL is READ OUT OF THE ARTIFACT where the theme baked it at compile time rather than composed in the renderer. `url` is REQUIRED and is a URL, so this is the same bind PagerDuty's `delivery_method.url` was in, resolved with the same canon. `signing_secret` is the document's own masked form ******** on a field described as a MASKED value - mirroring a provider's redaction is not a placeholder, and there is no secret in this universe to redact. `scope-id` and `scope-type` are both declared required and are enforced (founder ruling 2026-09-05)

hello-15's TelemetryExporter. The 2026-09-05 reason was that `exporter.endpoint` is a HOSTNAME and `the org's own hosts are a THEME construction a renderer may not replicate (invariant #6)` - so the endpoint is BAKED BY THE THEME AT COMPILE TIME into `telemetry_exporter.endpoint` and read straight off the row here, never composed in the renderer. `headers` publishes the configured header NAMES with CircleCI's own masked value, the same posture the context environment-variable row takes; `issues` is an honest empty, because an exporter this universe never failed to deliver through has none. `org-id` is declared REQUIRED, so a request without it is not a request this operation accepts

refuse — a usage export job is created by a POST this replica refuses, so no job id can exist - CircleCI's own 404 for an object that was never created is the whole answer