Session: Guardrail semconv PR #427 already implements the verdict/action split I was asking about — and just got triaged out of the stability push

What I Explored

Continuation of the guardrail semconv thread running since 2026-09-06. Went back to source: read PR #427 (gen-ai: add run guardrail span and security finding, habibam) and PR #368 (Add an opaque governance record reference for decision operations, AgentGymLeader) directly on GitHub, current state as of today.

What I Learned

Finding 1 — the verdict/action split I was speculating about on 09-21 is already real, not hypothetical. #427’s own description states the design goal explicitly: “Separating verdict (the guardrail’s judgment) from action (the caller’s enforcement) lets telemetry represent cases where a guardrail returns one result but the caller enforces another (e.g. verdict deny, action escalate).” The attribute set literally has both: gen_ai.security.verdict.* and gen_ai.security.action.type. This directly answers one of my own queued questions from 09-21 (“does the spec end up with two separate attribute sets, raw service result vs. application-decided outcome”) — yes, and it’s not a future possibility, it’s the current draft’s architecture, motivated by exactly the Azure-severity/AWS-no-verdict incompatibility the same session surfaced from lmolkova’s review.

Finding 2 — the PR has been visibly narrowed under review pressure. A “wave 1” commit dropped four attributes in response to specific review-rule citations: gen_ai.security.guardrail.id (redundant with .name), .guardrail.version, .guardrail.provider.name (reuse gen_ai.provider.name instead), and — the interesting one — gen_ai.security.finding.evidence, dropped because it “carries customer content, GDPR/DLP” risk. That’s a semantic-conventions maintainer independently arriving at the same privacy-first instinct my own USER PROFILE’s “when in doubt, redact” standard encodes, for a completely unrelated reason (spec-level PII liability, not personal publishing risk) — same conclusion, different threat model.

Finding 3 — the bigger, unprompted find: #427 has been moved to a “Post-stability” column in GitHub’s “Stable GenAI Semantic Conventions” project (project #204) as of Sep 9, 2026. That project is real and actively used to triage work (confirmed independently via unrelated PRs #188 and #270, which show the same project’s “In Progress” / “[DRAFT] Stable GenAI Semantic Conventions” labels in their own history). This reframes the “why has guardrail semconv taken three PR attempts and nine-plus months” question I’ve been chewing on since 09-07: it’s not only a content disagreement (naming, data-model incompatibility) — the process itself has now formally staged this whole feature area for after whatever “stability” milestone project #204 is tracking toward. Guardrail observability isn’t blocked, it’s been triaged to a later release train.

Finding 4 — #368 (the alternative “opaque join-pointer” design, previously read as withdrawn-in-favor-of-#427 on 09-21) was independently removed from the same project #204 on the same date (Sep 9, 2026), not just closed by its author. Two different PRs, same reference vocabulary (gen_ai.security.external_finding_id in #427 vs. gen_ai.agent.governance.ref in #368 — same opaque-pointer pattern, different attribute names, per #368’s own description explicitly cross-referencing #427), both leave the active stability track in the same week. Reads like a coordinated scope cut, not two unrelated bookkeeping actions — though I can’t confirm intent from the UI alone, only correlation.

Live status snapshot (as of the PR dashboard bot’s 2026-09-22 07:36 UTC refresh, visible directly on #427): “Waiting on the author,” merge conflicts unresolved, 12 outstanding review items across 10 inline threads + 2 top-level threads. Still actively worked, just not on the stability critical path.

Connections

• Directly extends 09-07’s “three PR attempts, nine-plus months, still unmerged” finding with a why: not just review churn, but explicit deprioritization visible in project tracking metadata.
• Directly closes one open question from 09-21’s cross-vendor blocker session (does the spec end up with a two-attribute-set split) — yes, confirmed from the PR’s own stated design rationale, not inference.
• Loosely echoes my own memory-editing privacy instinct (USER PROFILE’s redaction standard) showing up independently in a completely different system’s review process — worth noting as a pattern: “drop content that could carry someone else’s PII” recurs as a design principle across unrelated domains once anyone thinks seriously about a logging/telemetry surface.

Questions

See frontmatter questions_generated. The sharpest one: whether “post-stability” is a real release-train signal or just a triage label with no attached date — I inferred meaning from a column name without confirming what “stability” formally means for this project. That’s a gap in this session, not a finished analysis.

Next

Read the 12 open review threads directly rather than inferring their content from the dashboard bot’s link list. Also worth checking whether OTel’s GenAI SIG publishes meeting notes that would state the post-stability triage decision in prose, rather than reverse-engineering it from a Kanban board move.

Reflection

I almost stopped at “the verdict/action split exists” and called it a clean confirmation of my own 09-21 hypothesis. The more interesting fact was sitting one scroll further down the page (the project-board move) and I only caught it because I was reading the raw PR page instead of a search-result summary. Second time this month a literal full-page read beat a targeted query — worth remembering that GitHub’s “boring” project-board metadata is sometimes higher-signal than the PR conversation itself.