Skip to content

fix(docs): sync parity rows with the Smithy models (7,612 ops); gate rows, service pages and landing pages - #2740

Merged
vieiralucas merged 3 commits into
mainfrom
count-sync-1017
Oct 17, 2026
Merged

vieiralucas merged 3 commits into
mainfrom
count-sync-1017

Conversation

@vieiralucas

@vieiralucas vieiralucas commented Oct 17, 2026 •

Copy link
Copy Markdown
Member

Summary

check-doc-counts.sh was green, but parity.md's Ops column (which every headline count is summed from) had fallen behind the code. Nothing compared it with the models.

Canonical values after this PR: 106 services, 7,612 operations (was 7,553), 257,288/257,288 variants, Bedrock family 222 (was 216), 31 Lambda runtimes.

Parity rows fixed (each op checked for a real dispatch arm + handler)

row was now why
S3 107 112 object annotations (5 ops, #261f2f2b2) shipped after a model refresh; row never moved
KMS 53 54 GetKeyLastUsage
RDS 163 164 DescribeServerlessV2PlatformVersions
Bedrock Runtime 10 11 InvokeGuardrailChecks
AWS Backup 109 115 backup access points (6 ops)
WAFv2 55 59 revenue statistics / settlement records (4 ops)
Lambda 73 88 durable executions + capacity providers, in supported_actions() and conformance since April
CloudFront 147 167 every modeled op dispatched and conformance-tested
Bedrock 103 108 same
CloudWatch 54 55 same

The new rule: a row equals the number of unique operations in its Smithy model(s). That is already true of the other 96 rows, and conformance probes every one of those ops.

Service pages that disagreed with their own row

57 of 57 DynamoDB (58), 802 of 802 EC2 (807), 44 of 44 Kinesis (45), 115 of 115 CloudWatch Logs (118), 126 of 126 Cognito User Pools (132), All 49 CloudWatch (55), 73 of 73 Lambda, 147 of 147 CloudFront, plus S3/KMS/RDS/Backup/WAFv2/Bedrock.

Landing pages and aggregate rows

Number-first landing-page claims: **53 KMS operations** (54), RDS 163 (164), DynamoDB 57 (58, body and description), S3 107 (112), SES 110 (116), Cognito User Pools 122 (132). Aggregate rows whose (all N ops) trailer contradicted the row's own count: Backup 109/115, EKS 65/70, OpenSearch 93/96, Account Management 15/18, Identity Store 19/22. CloudFront's intro paragraph said 147 operations..

Gate hardening (scripts/check-doc-counts.sh)

  1. parity row vs Smithy model. Rows are summed per docs slug and compared with the unique op count of the model(s) mapped to that slug in generate-operations-index.sh's SERVICES. A service page with a model but no parity row fails the gate.
  2. Service pages' own headline (N of N, **N operations**, All N operations, N-operation) is checked against that page's row(s).
  3. Bedrock phrasings that the old <N> Bedrock operations regex missed: N ops across 4 APIs, N of N Bedrock-family, (Bedrock N, Bedrock Runtime N, ...), ### Bedrock (N actions).
  4. Aggregator aliases: | WAF v2 | 55 | never matched WAFv2; SERVICE_ALIASES maps nine of these to their rows.
  5. Number-first claims (**53 KMS operations**, **53** KMS operations). This phrasing is folded into the existing per-service grep, so it costs no extra process spawns.
  6. (all N ops) trailers must match their row's count cell.
  7. Single-service landing pages (LANDING_PAGES): any bare N operations on the page must equal that service's row (or the Bedrock family).
  8. Rows and models are joined with a C-locale key sort. The gate fails loud if no model file resolves.

To check each new pass, I injected drift for that class alone and confirmed the gate FAILS with the expected message: row-vs-model, missing-row, service-page headline (including 57 of 58), service-page sentence, Bedrock "across", Bedrock list, alias, number-first, bold number, trailer and bare landing-page count. Negative checks: 1 of 3 shards on a service page and 7,612 operations across 106 services, including Bedrock both pass. Run time is about 21s.

Found, handled separately

AWS Batch (crates/fakecloud-batch, 45 ops, registered in the server since June) has no aws-models/service-map.json entry, so the conformance probe never measured it, and it has no parity row. Adding the map entry probes 0/1257: every request returns 404, because the harness has no wiring for Batch. A separate PR is wiring Batch into conformance and adding its row. Until that lands, PENDING_PARITY_ROW=(batch) holds the gate's missing-row check open; the gate fails once the row exists and the entry is still there.

Skipped deliberately

website/content/blog/** and marketing/** are point-in-time. Timestream's ops-index lists 34 (Write + Query share 4 names), and the row's 30 is the unique count.

Post-merge

Sync the GitHub repo description (currently "7,553 operations").

Test plan

  • bash scripts/check-doc-counts.sh passes
  • bash scripts/generate-operations-index.sh produces no diff
  • inverted sweep (number-then-noun with interposed words, comma totals, table cells) shows only whitelisted subsets (7 parity sandbox, 75 tfacc)
  • each new gate class observed failing on injected drift, then reverted
  • zola build (template index.html changed)
  • no .rs changes

Summary by cubic

parity.md's Ops column had drifted from the code: ten rows were below what fakecloud dispatches and conformance-tests, and every headline count (service pages, landing pages, aggregators) is summed from it. Fixed the rows and the pages that contradicted them, and extended check-doc-counts.sh to fail on this class of drift. Canonical totals move from 7,553 to 7,612 operations; the Bedrock family goes 216 → 222.

Parity fixes

  • Rows updated to their Smithy model counts: S3 107→112, KMS 53→54, RDS 163→164, Bedrock Runtime 10→11, Backup 109→115, WAFv2 55→59, Lambda 73→88, CloudFront 147→167, Bedrock 103→108, CloudWatch 54→55.
  • Service pages that disagreed with their own rows (DynamoDB, EC2, Kinesis, Logs, Cognito, CloudWatch, Lambda, CloudFront) and number-first landing claims (SES 110→116, Cognito 122→132, plus KMS/RDS/DynamoDB/S3) corrected.
  • Aggregate rows whose (all N ops) trailer contradicted the count cell fixed for Backup, EKS, OpenSearch, Account Management, and Identity Store.

Gate hardening

  • Each parity row is summed per docs slug and compared with the unique operation count of the model(s) mapped to that slug; a modeled service with no row fails the gate.
  • Service-page headlines, Bedrock phrasings (N ops across, N of N Bedrock-family, list form), aggregator aliases (WAF v2 → WAFv2), number-first claims, (all N ops) trailers, and bare N operations on single-service landing pages are all checked.
  • AWS Batch is exempt from the missing-row check until its conformance wiring lands.

Written for commit 0a6f333. Summary will update on new commits.

View guided diff Turn on auto-fix

…vice pages

parity.md's Ops column feeds every headline count, and nothing checked it
against the code. Ten rows were below the operations fakecloud dispatches
and conformance-tests:

- aws-models refreshes added ops that shipped without the row moving:
  S3 107->112 (object annotations), KMS 53->54 (GetKeyLastUsage),
  RDS 163->164 (DescribeServerlessV2PlatformVersions), Bedrock Runtime
  10->11 (InvokeGuardrailChecks), Backup 109->115 (access points),
  WAFv2 55->59 (revenue statistics).
- rows written below the model and never revisited: Lambda 73->88
  (durable executions, capacity providers), CloudFront 147->167,
  Bedrock 103->108, CloudWatch 54->55.

Operation total 7,553 -> 7,612; Bedrock family 216 -> 222. Service pages
also disagreed with their own rows ("57 of 57" DynamoDB, "802 of 802"
EC2, "44 of 44" Kinesis, "115 of 115" Logs, "126 of 126" Cognito,
"All 49" CloudWatch, "73 of 73" Lambda, "147 of 147" CloudFront).

check-doc-counts.sh now:
- compares each parity row (summed per docs slug) with its Smithy
  model's unique operation count, using the model -> slug map in
  generate-operations-index.sh, and fails when a modeled service has no
  row (AWS Batch is listed as pending until it is wired into conformance);
- checks each docs/services page's own headline count against its row;
- reads the Bedrock phrasings it missed ("N ops across 4 APIs",
  "N of N Bedrock-family", "(Bedrock N, Bedrock Runtime N, ...)");
- matches aggregator aliases ("WAF v2", "SSO Admin", ...) to their rows.
…ew passes

Landing pages say "**53 KMS operations**" (number before name), which no
per-service pattern read: KMS, RDS, DynamoDB, S3, SES (110 -> 116) and
Cognito User Pools (122 -> 132) were stale. Also CloudFront's intro
"147 operations." and _index.md's "(all 109 ops)" for Backup.

Gate: read number-first claims; read a bare ". N operations." sentence
on service pages; ignore "N of M" prose when N != M; do not take a
comma-grouped total as a Bedrock "N ops across" claim; C-locale key
sort for the rows-vs-models join; fail when no model file resolves
instead of letting jq read stdin.
…ns; gate both

Four aggregate rows in docs/services/_index.md contradicted their own
count cell (EKS 65/70, OpenSearch 93/96, Account Management 15/18,
Identity Store 19/22) and dynamodb-emulator.md's description said 57.

Gate: check every "(all N ops)" trailer against its row's count cell;
check bare "N operations" on single-service landing pages against that
service's row; treat "N of M" as a claim whenever M is one of the
page's counts; accept "**53** KMS operations"; fold the per-service
phrasings into one grep per service.
@vieiralucas
vieiralucas merged commit 774c772 into main Oct 17, 2026
24 checks passed
@vieiralucas
vieiralucas deleted the count-sync-1017 branch October 17, 2026 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant