The standards reference card, with critiques

What it is

A named standard is a decision you do not have to make and an argument you do not have to win. The value of knowing them is that you can say "CloudEvents" instead of designing an envelope format, and that you can say which part of a standard is weak instead of adopting it whole.

This page is a reference card: what each standard is for, when it matters, and the specific criticism worth knowing.

What this is confused with: standards as compliance. Nobody is checking. A standard is adopted because it saves design time, gives you tooling for free, and makes an interface legible to someone who has never seen your system and because deviating from one is a cost you should have to justify.

Also confused: a standard and a specification you must implement fully. Most of these are adopted in part. The useful skill is knowing which part is load-bearing, for example that OAuth without PKCE is a different security posture, or that CloudEvents' value is the attribute names rather than the transport bindings.

The problem it solves

Every standard on this card exists because a category of system kept inventing the same thing badly.

Before                            The standard
--------------------------------------------------------------
every service invented its own    RFC 7807 / 9457 problem
error body                        details

every team invented an event      CloudEvents
envelope with a slightly
different id/time/type

every tracing vendor propagated   W3C Trace Context
a different header, so traces
broke at every boundary

every API documented itself in a  OpenAPI
wiki page that was wrong

every company built its own       SPIFFE, OIDC
service identity

every vulnerability scanner       SPDX / CycloneDX
consumed a different inventory
format

And the cost of not adopting one is rarely the design time, it is the tooling. An OpenAPI document gets you client generation, mock servers, contract tests, a request validator and a gateway configuration for free; a wiki page gets you nothing.

Mechanics

API and interface

REST / HTTP semantics       RFC 9110 (semantics), 9111
                            (caching), 9112 (HTTP/1.1)
  What matters: method safety and idempotency (GET/HEAD/PUT/
  DELETE idempotent, POST not), status code meaning, and
  conditional requests (ETag, If-Match) for optimistic
  concurrency.
  CRITIQUE: "RESTful" in practice means "JSON over HTTP", and
  the Richardson maturity model's level 3 (HATEOAS) is
  essentially unused outside a few domains. Do not defend
  hypermedia in an interview unless you have shipped it; do
  defend correct status codes and idempotency.

OpenAPI 3.1
  Machine-readable HTTP API description. Generates clients,
  servers, mocks, validators and gateway config.
  CRITIQUE: 3.1 aligned with JSON Schema 2020-12, which fixed
  a long-standing divergence and broke tooling that had not
  caught up. Also: generated clients are frequently worse
  than hand-written ones, and the document drifts from the
  implementation unless it is generated from code or verified
  in CI.

JSON Schema (2020-12)
  Validation and description of JSON.
  CRITIQUE: it is a draft series, not an RFC, and version
  differences between drafts are a real source of tooling
  pain. `$ref` resolution across documents is where most
  problems live.

gRPC / Protocol Buffers
  Binary, schema-first, HTTP/2, streaming, code generation.
  CRITIQUE: field numbers are the contract, not names, so
  renaming is free and renumbering is catastrophic. proto3
  removed required and made every scalar have a default,
  which means you cannot distinguish "absent" from "zero"
  without wrappers or `optional` (restored in 3.15). And
  browser support needs grpc-web or Connect.

GraphQL
  Client-specified queries over a typed schema.
  CRITIQUE: it moves complexity from the client to the server:
  N+1 resolution needs DataLoader, caching is hard because
  every query is a POST with a different body, and query cost
  must be bounded or a single query can table-scan your
  database. Federation is genuinely good and genuinely
  complex.

AsyncAPI
  OpenAPI's shape for event-driven interfaces.
  CRITIQUE: much thinner tooling than OpenAPI, and the 3.0
  rework changed the model. Worth adopting for documentation
  value more than for generation.

CloudEvents (CNCF)
  A standard envelope for events: id, source, type, time,
  subject, datacontenttype, plus bindings for HTTP, Kafka,
  AMQP.
  CRITIQUE: it standardises the envelope and says nothing
  about the payload, which is where the actual compatibility
  problems are. Its value is real and narrow: stop inventing
  the outer fields.

RFC 9457 (formerly 7807) Problem Details
  A standard error body: type, title, status, detail,
  instance.
  CRITIQUE: nearly free to adopt, and the failure is leaking
  internal detail into `detail`. Also `type` is supposed to be
  a dereferenceable URI and almost nobody dereferences it.

Idempotency-Key
  An IETF draft (widely implemented before standardisation)
  for safe POST retries. Stripe's implementation is the de
  facto reference.
  CRITIQUE: still a draft, so implementations differ on
  whether the key scopes to the endpoint, the account, or
  the request body hash. Specify yours.

Identity and authorisation

OAuth 2.0 (RFC 6749) and OAuth 2.1 (draft, consolidating)
  DELEGATED AUTHORISATION. Not authentication.
  CRITIQUE: 2.0 is a framework with insecure options still in
  it. 2.1 removes the implicit grant and the password grant
  and requires PKCE for all clients, which is the shape you
  should be building to regardless of its status.

PKCE (RFC 7636)
  Proof key for code exchange. Required for public clients,
  and now recommended for ALL clients.
  CRITIQUE: none worth making. Its absence is the finding.

OpenID Connect
  AUTHENTICATION on top of OAuth 2.0, adding the ID token.
  CRITIQUE: the distinction from OAuth is the thing candidates
  get wrong: an access token says what you may do, an ID token
  says who you are, and using an access token as proof of
  identity is a common and real vulnerability.

JWT (RFC 7519), JWS (7515), JWE (7516)
  CRITIQUE: the format has a poor security record, and the
  reasons are worth knowing: `alg: none`, algorithm confusion
  (RS256 verified as HS256 using the public key as an HMAC
  secret), and unbounded lifetime because there is no
  revocation. Always pin the expected algorithm, validate
  `iss`/`aud`/`exp`, and keep lifetimes short. For sessions,
  an opaque token with server-side state is usually the better
  choice and gets dismissed for the wrong reason ("it does not
  scale").

SAML 2.0
  XML-based enterprise SSO. Still ubiquitous in B2B.
  CRITIQUE: XML signature wrapping and canonicalisation
  attacks have a long history, and implementing it yourself is
  a bad idea. Use a library, and expect enterprise customers
  to require it regardless of your preference for OIDC.

SCIM (RFC 7643/7644)
  Standard user and group provisioning.
  CRITIQUE: unglamorous and the thing enterprise deals turn
  on. Implementations vary enough that "SCIM compliant" needs
  per-IdP testing.

SPIFFE / SPIRE
  Workload identity: a cryptographic identity (SVID) issued to
  a workload rather than to a person, with short-lived certs.
  CRITIQUE: the concept is right and adoption is mostly via a
  service mesh rather than directly, so most teams get SPIFFE
  identities without ever naming them.

WebAuthn / FIDO2
  Phishing-resistant authentication with hardware-bound
  credentials; passkeys are the consumer packaging.
  CRITIQUE: account recovery is the hard part and the
  specification does not solve it for you, which is where
  most rollouts stall.

Observability

W3C Trace Context
  traceparent and tracestate headers.
  CRITIQUE: it is the reason traces survive vendor and
  organisational boundaries, and its absence is why they used
  not to. Baggage (a companion spec) propagates application
  key-values and is a cardinality hazard.

OpenTelemetry
  API, SDK, OTLP protocol, Collector, semantic conventions.
  CRITIQUE: the semantic conventions churned on the way to
  stability, so dashboards and alerts referencing older
  attribute names break. Per-language and per-signal maturity
  varies.

Prometheus exposition / OpenMetrics
  The de facto metrics scrape format.
  CRITIQUE: label cardinality is the cost model and nothing in
  the format stops you exploding it.

Supply chain and packaging

SBOM: SPDX (ISO/IEC 5962) and CycloneDX (OWASP)
  A machine-readable inventory of what is in a build.
  CRITIQUE: two competing formats, both viable, and
  translation between them is lossy. An SBOM's value is
  entirely downstream: it is worthless unless something
  consumes it and alerts.

SLSA
  A framework of levels for build-provenance integrity.
  CRITIQUE: the levels are useful as a shared vocabulary for a
  roadmap, and claiming a level without the tamper-resistant
  build platform that backs it is common.

Sigstore (cosign, Fulcio, Rekor)
  Keyless signing with short-lived certificates and a
  transparency log.
  CRITIQUE: it solves key management by removing long-lived
  keys, and it moves your trust to the identity provider and
  the log, which is a trade to state rather than to ignore.

Semantic Versioning
  MAJOR.MINOR.PATCH.
  CRITIQUE: it depends on the publisher's judgment about what
  breaks, and Hyrum's law says every observable behaviour is
  depended on by someone, so a patch release breaks somebody.
  Useful as a communication convention, not as a guarantee.

Data and time

RFC 3339 / ISO 8601
  Timestamps. RFC 3339 is the strict internet profile.
  CRITIQUE: always store and transmit UTC with an explicit
  offset, and store the ORIGINATING TIME ZONE separately when
  the local wall-clock time matters, because a future
  appointment in a zone whose rules change is not recoverable
  from an instant alone.

UUID (RFC 9562)
  v4 random, v7 time-ordered.
  CRITIQUE: v4 as a primary key in a B-tree index causes
  random insert locations and page splits. v7 is
  monotonic-ish and is the current right default for a
  database key. Knowing v7 exists is a recency signal.

RFC 9111 (HTTP caching) and RFC 5861
  Cache-Control semantics, plus stale-while-revalidate and
  stale-if-error.
  CRITIQUE: the two RFC 5861 extensions are the highest-value
  and least-used part of HTTP caching, and they are what ISR
  implements at the page layer.

Using the card in an interview

The signal is not reciting names. It is:

  1. NAMING THE RIGHT ONE UNPROMPTED.
     "That envelope is CloudEvents, so we do not design it."

  2. KNOWING WHICH PART IS LOAD-BEARING.
     "OAuth without PKCE is a different security posture."
     "In protobuf the field number is the contract, not the
      name."

  3. HAVING A CRITIQUE.
     "SemVer is a communication convention, not a guarantee,
      because Hyrum's law means every observable behaviour is
      depended on by someone."

  4. KNOWING WHEN NOT TO ADOPT ONE.
     GraphQL for a two-consumer internal API is a cost with no
     benefit. SCIM before you have an enterprise customer is
     work with no buyer.

A worked example: an integration platform that standardised four things

A B2B integration platform: 11 partner integrations, a public API, an event stream consumed by customers, and a stalled enterprise deal. Four decisions were made in one architecture review.

1. Error responses.

Before: 6 different error shapes across the public API,
  because each was written by a different team.
    {"error": "..."}                 (3 endpoints)
    {"message": "...", "code": 4001} (12)
    {"errors": [{"detail": "..."}]}  (7)
    plus a plain string body          (2)

Partner integration teams each wrote a parser per shape, and
two of them silently swallowed the plain-string case.

Adopted RFC 9457 problem details, with a registry of `type`
URIs owned by the platform team, and a gateway-level
translation layer so existing endpoints did not have to change
on day one.

Measured: partner-reported "we could not tell why it failed"
tickets fell from ~9/month to 1/month over two quarters. The
gateway translation was 140 lines.

The gateway translation is the reason this was a two-week change rather than a two-quarter one, and it is the same argument as doing semantic-convention renames in an OpenTelemetry Collector.

2. The event stream envelope.

Before: an envelope invented in 2019 with fields
  {eventId, eventType, timestamp, payload, version}
  and three inconsistencies: timestamp was epoch millis in
  two topics and RFC 3339 in the rest; version meant schema
  version in one place and API version in another; and there
  was no source field, so a customer consuming two of our
  streams could not tell them apart.

Adopted CloudEvents 1.0, with the Kafka binding.
  id, source, type, time, subject, datacontenttype,
  dataschema, data

What it bought: customers' existing CloudEvents tooling
worked, the source field resolved the ambiguity, and time was
unambiguous.

What it did NOT buy, and was stated explicitly in the ADR:
CloudEvents says nothing about the payload, so the actual
compatibility discipline (additive-only changes, a schema
registry) was still entirely ours to enforce. Adopting the
envelope was not a compatibility strategy.

Writing "this standardises the envelope and not the payload" into the ADR prevented the predictable later belief that adopting CloudEvents had solved schema evolution.

3. Authentication, which was the stalled deal.

The enterprise customer required SAML SSO and SCIM
provisioning. The platform had OAuth 2.0 with an in-house
user API.

The engineering preference was strongly for OIDC, on the
grounds that SAML is XML, has a poor security history, and is
"legacy".

The decision: implement both, using a library for SAML, and
do not argue. The customer's identity provider was the
constraint and it was not going to change for a supplier.

Second finding, from the same review: the existing OAuth
implementation had no PKCE, and the mobile client used the
implicit grant, which OAuth 2.1 removes. That was a
pre-existing security issue found only because someone read
the current standard rather than the one they had learned.

Fixed: authorisation code with PKCE for all clients, implicit
grant removed.

SCIM took 5 weeks and had to be tested against three different
identity providers, because "SCIM compliant" varies in
practice.

The PKCE gap was found by reading the current standard rather than the one the team learned, which is the practical argument for keeping a reference card current rather than for having memorised one once.

4. Primary keys, which was the cheapest change with the largest measured effect.

The events table used UUIDv4 primary keys, 340 million rows,
Postgres.

Symptom nobody had diagnosed: insert throughput degraded as
the table grew, and the index was much larger than expected.

Cause: random UUIDs insert at random positions in a B-tree, so
every insert dirties a different page, page splits are
frequent, and the working set for inserts is effectively the
whole index rather than its right edge.

Changed new rows to UUIDv7 (time-ordered, RFC 9562).

Measured over the following quarter:
  insert throughput            +38%
  index size for new partitions -22%
  WAL volume                    -19%
  buffer cache hit ratio for
    the index                   91% -> 99%

Existing rows were left alone; the change applied to new
partitions only, so it required no migration.

A one-line change to an ID generator producing a 38 percent insert throughput improvement is the strongest single argument on this page for keeping current with standards, because UUIDv7 was standardised in 2024 and the team's default was chosen years earlier.

What was deliberately not adopted:

GraphQL was proposed for the public API. Rejected: two
  consumer shapes, both well served by REST, and the N+1,
  caching and query-cost work would have been a quarter with
  no user-visible benefit.

AsyncAPI was proposed for the event stream. Deferred: the
  documentation value was real, the tooling was thin, and the
  CloudEvents envelope plus a schema registry already covered
  the machine-readable part.

SLSA level 3 was proposed. Scoped down to level 1 plus
  Sigstore signing, with a written note that claiming a higher
  level without a tamper-resistant build platform is a claim
  the platform does not support.

Two of the four adoptions were driven by a customer requirement rather than by engineering preference, which is the ordinary shape of standards work and is worth saying in an interview, because it is more honest than a narrative in which every adoption was an architectural insight.

Production evidence

RFC 9457 obsoletes RFC 7807 and defines the problem-details media type; it is implemented natively by ASP.NET Core, Spring Boot's ProblemDetail, and several API gateways, which is why adoption is usually configuration rather than code.

CloudEvents is a CNCF graduated specification with bindings for HTTP, Kafka, AMQP, MQTT and NATS, and SDKs in ten languages; Azure Event Grid, Knative Eventing and Google Eventarc emit it natively.

OAuth 2.1 consolidates OAuth 2.0 with the security best-current-practice guidance, removing the implicit and resource-owner-password grants and requiring PKCE for all clients; the underlying recommendations were published as an IETF BCP before the consolidation.

JWT's documented weaknesses, alg: none acceptance and RS256-to-HS256 algorithm confusion, are catalogued in the JWT best-current-practice RFC (8725) and were the basis for widely publicised library vulnerabilities.

UUID version 7 is defined in RFC 9562 (2024), which obsoletes RFC 4122 and standardises time-ordered UUIDs specifically to address the index-locality problem with version 4; the throughput and index-size effects are widely reproduced in database benchmarking write-ups.

W3C Trace Context is a W3C Recommendation and is what allows a trace to cross vendor and organisational boundaries; OpenTelemetry's adoption of it is why cross-vendor tracing works at all.

SPDX is ISO/IEC 5962 and CycloneDX is an OWASP project and Ecma standard; the coexistence of two formats, and the lossiness of conversion between them, is documented by tooling that supports both.

Hyrum's law, that with a sufficient number of users every observable behaviour of a system will be depended upon, is the standard argument for why semantic versioning is a communication convention rather than a guarantee.

The debate

Should you always adopt the standard? No. Adopt one when it saves design time, brings tooling, or is a customer requirement, and skip it when it is work with no buyer: SCIM before an enterprise customer, GraphQL for a two-consumer internal API, AsyncAPI where the tooling is thinner than the documentation you already have. The default should be adoption, because deviating is a cost you should have to justify, and the exceptions should be stated.

Is REST or gRPC the right internal default? gRPC for internal service-to-service, for the schema, the code generation and the streaming. REST for anything a browser or a partner touches, because the tooling and the debuggability are unmatched and a partner integrating with your API on a Tuesday afternoon can use curl. GraphQL when many clients need many different shapes of the same data, which is a real condition and a narrower one than its adoption suggests.

Are JWTs a good session mechanism? Usually not. They cannot be revoked, so a compromised token is valid until expiry, and short expiry means a refresh mechanism that reintroduces the server-side state you were avoiding. Opaque tokens with server-side sessions are dismissed on scalability grounds far more often than the scalability is measured. JWTs are genuinely right for short-lived, service-to-service, stateless assertions, which is what they were designed for.

Is SemVer worth following? As a communication convention, yes. As a guarantee, no, because Hyrum's law means a patch release breaks somebody, and the honest practice is to pair it with a deprecation policy and a support window rather than to pretend the version number is a contract.

Is an SBOM useful? Only if something consumes it. An SBOM generated in CI and stored in a bucket is theatre; an SBOM ingested by a scanner that alerts on a new CVE affecting a shipped artifact is the control. The format choice between SPDX and CycloneDX matters far less than whether the pipeline exists.

Should you implement SAML in 2026? If an enterprise customer requires it, yes, using a library, and without arguing. The engineering preference for OIDC is correct and irrelevant, because the customer's identity provider is the constraint and it will not change for a supplier.

Follow-up Q&A

"Why adopt a standard rather than design your own?"

Because the design time is usually the smaller saving and the tooling is the larger one. An OpenAPI document gets you client generation, mock servers, request validation, contract tests and gateway configuration; a wiki page gets you nothing. A CloudEvents envelope means your customers' existing tooling works on your stream. And a standard makes an interface legible to someone who has never seen your system, which is the property that matters at an organisational boundary. The default should be adoption, with deviations stated and justified.

"Which parts of OAuth actually matter?"

That it is delegated authorisation and not authentication, so an access token says what you may do and an ID token from OpenID Connect says who you are; using an access token as proof of identity is a real and common vulnerability. And PKCE, which OAuth 2.1 requires for all clients rather than only public ones. In one review the existing implementation had no PKCE and the mobile client used the implicit grant, which 2.1 removes entirely, and that was found only because someone read the current standard rather than the one they had learned.

"What is wrong with JWTs?"

Three things worth knowing. The historical vulnerabilities: alg: none acceptance and algorithm confusion, where an RS256 token is verified as HS256 using the public key as the HMAC secret, both of which are why you must pin the expected algorithm rather than trust the header. No revocation, so a compromised token is valid until it expires, and short expiry means a refresh mechanism that reintroduces server-side state. And they are frequently chosen for sessions on scalability grounds that nobody measured. They are genuinely right for short-lived stateless service-to-service assertions.

"What does CloudEvents actually give you?"

A standard envelope: id, source, type, time, subject, content type, schema reference. That is real and narrow. It resolves the ambiguities teams reinvent, in one case a timestamp that was epoch millis in two topics and RFC 3339 in the rest, and a missing source field so consumers could not tell two of the same producer's streams apart. What it explicitly does not give you is anything about the payload, so additive-only schema evolution and a schema registry remain entirely your problem. Writing that into the ADR is what prevents the later belief that adopting the envelope solved compatibility.

"Why does UUIDv7 matter?"

Because a version 4 UUID is random, so as a B-tree primary key every insert lands at a random position, dirties a different page, causes frequent page splits, and makes the working set for inserts effectively the whole index rather than its right edge. Version 7, standardised in RFC 9562, is time-ordered, so inserts append. In one case switching new partitions to v7 improved insert throughput 38 percent, cut index size 22 percent and WAL volume 19 percent, and took the index buffer cache hit ratio from 91 to 99 percent, with no migration because it applied only to new rows.

"When should you not adopt a standard?"

When it is work with no buyer. SCIM before an enterprise customer requires it. GraphQL for an API with two well-understood consumers, where you would take on N+1 resolution, caching difficulty and query-cost bounding for no user-visible benefit. AsyncAPI where the tooling is thinner than the documentation you already maintain. And claiming a SLSA level whose requirements your build platform does not meet, which is a claim rather than a control.

What is the Twelve-Factor App, and how much of it still holds? It is a 2011 methodology from Heroku, twelve rules for services that are portable and disposable: strict separation of config from code (config in the environment, never in the repo), explicit and isolated dependency declaration, treating backing services as attached resources addressed by URL, a strict separation of build, release and run stages, stateless processes, port binding, scaling by process model, fast startup and graceful shutdown, dev/prod parity, logs as an event stream written to stdout rather than to files, and admin tasks as one-off processes. Most of it is now so thoroughly absorbed into how containers work that it reads as description rather than advice, which is the highest compliment a methodology gets: a container image is the build/release/run separation, and a Kubernetes ConfigMap is config in the environment.

Three factors have aged less well and are worth having an opinion about. "Logs as an event stream to stdout" predates structured logging and OpenTelemetry, and the modern form is structured events with trace context, where stdout is one possible transport rather than the model. "Stateless processes" was written before StatefulSets and before operators made stateful workloads routine, so the rule is better stated as "keep state in a backing service, and know which of your processes is the exception". And the treatment of concurrency assumes a process-per-unit model that virtual threads and async runtimes have complicated. Citing Twelve-Factor is fine; citing it as though nothing has happened since 2011 is a dated signal.

Which governance frameworks should you be able to name, and what is each actually for? Four, and the distinction between them is the answer. NIST CSF 2.0 (2024) is the cybersecurity framework, organised around six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is the one added in 2.0 and it matters, because it moved cybersecurity from a technical programme to an enterprise risk one with named accountability. CSF is deliberately outcome-based rather than prescriptive, so it is a common language for describing your posture rather than a checklist you pass. ISO/IEC 27001 is the certifiable information security management standard, and the difference from CSF is exactly that: 27001 you get audited against and hold a certificate for, CSF you self-assess with.

For AI specifically, the NIST AI Risk Management Framework (AI RMF 1.0, 2023) is the voluntary counterpart, organised around Govern, Map, Measure and Manage, with the emphasis on identifying context-specific harms rather than on a fixed control set. ISO/IEC 42001 (2023) is its certifiable sibling, an AI management system standard structured like 27001, and it is the one that will show up in enterprise procurement questionnaires because it produces a certificate. The relationship worth stating: NIST frameworks give you the vocabulary and the risk process; ISO standards give you something an auditor can sign. A team shipping AI features into regulated customers will be asked about 42001 by procurement long before anyone asks a technical question, and knowing that is a genuinely useful thing for a staff engineer to have in their head when a deal is blocked.

Common misconceptions

"REST means HATEOAS." In practice "RESTful" means JSON over HTTP, and level 3 of the maturity model is essentially unused. Defend correct status codes, safety and idempotency instead.

"OAuth authenticates users." It authorises delegated access. OpenID Connect adds authentication with an ID token, and using an access token as identity proof is a real vulnerability.

"JWTs scale better than sessions." They remove a lookup and add an inability to revoke. The scalability claim is usually asserted rather than measured.

"SemVer guarantees compatibility." It communicates the publisher's judgment. Hyrum's law means every observable behaviour is depended on by someone, so a patch release breaks somebody.

"CloudEvents solves event compatibility." It standardises the envelope and says nothing about the payload, which is where compatibility problems actually live.

"An SBOM improves security." Only if something consumes it and alerts. Generated and stored is theatre.

"UUIDs are UUIDs." Version 4 is random and hostile to B-tree insert locality; version 7 is time-ordered and is the current default for a database key.

Interview delivery note

Say this verbatim: "I adopt a standard for the tooling more than for the design: an OpenAPI document gets you generated clients, mocks, request validation and gateway config, and a wiki page gets you nothing. And the useful skill is knowing which part is load-bearing, like PKCE in OAuth, or that in protobuf the field number is the contract rather than the name." It states the real reason and demonstrates the depth in one example.

The senior-versus-staff separator is having a critique of each standard rather than a list. A senior engineer names CloudEvents. A staff engineer says CloudEvents standardises the envelope and says nothing about the payload, so additive-only schema evolution and a registry remain your problem, and then writes that into the ADR so that nobody later believes adopting it solved compatibility. The same move applies to SemVer as a convention rather than a guarantee, and to an SBOM being worthless unless something consumes it.

The second signal is reading the current version of a standard rather than the one you learned. In one review, finding that the mobile client still used the implicit grant and that no client used PKCE came from reading OAuth 2.1's consolidation, and switching new rows to UUIDv7 came from RFC 9562 being published after the team's default was chosen. Both were cheap changes with measurable effects that nobody would have found from memory.

The Staff & Team Lead Interview Reference