RFC/tracking: emergent-observation design — application axes beyond spec-drift

[montfort]

Summary

Tracking issue for the four open application axes identified in `EMERGENT-OBSERVATION-DESIGN.md` §Open application axes — landed in `fw-4.17.0` (PR #160).

This issue is scope-defining, not implementation-bound. Like #153, it preserves context across cycles so that when a second domain ratifies one of these axes empirically, the upstream Charter can be designed cohesively rather than reactively.

Context

`fw-4.17.0` named the meta-pattern that produced Sentinel's spec-drift observation (#150 → #156): formal cross-referencing composed with cultural permission to surface. The new doc enumerates already-canonicalized applications of this meta (Pattern 1, Pattern 2, charter drift, follow-ups backlog drift, TDE-vs-`R` escalation, audit checkpoint) and identifies four loci where the structural infrastructure exists partially but the cultural permission or the application pattern has not been named.

These are the candidates for the next axis to crystallize once empirical N=1-domain evidence arrives. Principle #12 (validation against a second domain before crystallization) applies to each.

The four open axes

a) MCARD ↔ deployed model code

• What's missing: Charter telemetry has no `model-version-at-close` field; AILOGs have no `deployed_mcard:` linkage field; no drift detection pattern parallel to `check-followups-drift.sh` for model deployment vs MCARD on file.
• Detectable delta: MCARD describes model v2.1; production logs report v2.0. Or MCARD `status: accepted` but latest deployment AILOG references v2.1 without MCARD update.
• Closest precedent: MCARD template exists (`TEMPLATE-MCARD.md`); the pattern of surfacing drift between declared model and shipped model is not codified.

b) SBOM ↔ lockfiles

• What's missing: No canonical AILOG field linking to SBOM; no drift script comparing declared SBOM against actual `package.lock` / `requirements.txt`; no telemetry signal for dependency-change events.
• Detectable delta: SBOM declares `dep@v1.2.3`; lockfile has `v1.2.4`. Or security scanner flags CVE that SBOM hasn't been updated to reflect.
• Closest precedent: `AI-RISK-CATALOG.md §RISK-004` mentions SBOM maintenance for AI components but doesn't formalize the surfacing convention.

c) ADR vigente ↔ contradicting implementation

• What's missing: `charter-telemetry.schema.v0.json` already captures `decisions_contradicting_prior_adrs`, but no protocol tells the agent when to surface a contradiction it observes during implementation.
• Detectable delta: AILOG implements a change that contradicts a live ADR without documenting the transition (no `supersedes:` chain, no fresh ADR ratifying the new direction).
• Closest precedent: Sentinel `charter_telemetry` validated the signal exists across 4/4 cycles; the surfacing convention is the missing piece.

d) Constitution Check ↔ framework version bump

• What's missing: `SPECKIT-CHARTER-BRIDGE.md §Constitution Check re-evaluation cadence` codifies the cadence verbally (per-Charter, per-spec-refresh, NOT per-framework-bump alone); no automatic alert fires on `straymark update-framework`.
• Detectable delta: Charter declared against `fw-4.10` spec; framework bumps to `fw-4.17` between Charters; new gates in Constitution Check would yield different results, but no signal surfaces this to the operator.
• Closest precedent: The cadence rule itself was added in fw-4.14.3 (RFC/discussion: spec-refresh discipline in SPECKIT-CHARTER-BRIDGE — empirical staleness across multi-Charter execution #150); the mechanical surfacing is what's open.

Why these four belong in the same tracking issue

All four share the structural characteristics that defined the upstream-acceptance flow for Pattern 1 and Pattern 2:

1. The structural cross-referencing infrastructure is partial. Each axis has some of the pieces (template exists, telemetry field exists, cadence rule exists) but lacks at least one of: a canonical linkage field, a drift-detection convention, or a telemetry signal.
2. The cultural permission is implicit but not named. AGENT-RULES `§6 Be Proactive` and Principle fix: remove redundant header from framework update output #8 cover the general permission to surface dissonance, but each axis would benefit from being named explicitly as a watch-for example (like the five examples added to §6 in fw-4.17.0).
3. They have non-trivial design surface. Each axis touches a different layer of the framework (model artifacts, supply chain, architecture decisions, governance gates). Designing them in isolation risks calcifying choices that another axis will contradict.

What's explicitly out of scope for this tracking issue

• No implementation. This is a context preservation vehicle, not an RFC for any single axis.
• No design freeze. Each axis will be designed against its empirical evidence when that evidence arrives.
• No timeline commitment. Tied to whether a second adopter exercises any of these axes with real data — that's the natural trigger per Principle feat: add devtrail repair command to restore broken structure #12.

Acceptance flow when an axis ratifies

Per `EMERGENT-OBSERVATION-DESIGN.md` §Authority/acceptance flow for naming new meta-applications:

1. Adopter-local RFC at `.straymark/06-evolution/-rfc.md`.
2. Upstream Issue (a sibling of this one, scoped to the specific axis) with telemetry citations and PR links.
3. Upstream acceptance: update template/schema/governance to add the missing structural piece; add the axis to the Pyramid of instances table in EMERGENT-OBSERVATION-DESIGN.md; optional CLI scaffolding.
4. Second-domain validation before schema additions graduate from optional to recommended.

Cross-references

• RFC/discussion: spec-refresh discipline in SPECKIT-CHARTER-BRIDGE — empirical staleness across multi-Charter execution #150 (Sentinel CHARTER-17 — spec-refresh discipline RFC; gave rise to Pattern 1)
• RFC: Pre-declare SpecKit refresh + post-close Batch 7.4 — two patterns surfaced in Sentinel CHARTER-18 #156 (Sentinel CHARTER-18 — Pattern 1/2 upstreaming; `fw-4.16.0`)
• feat(framework): fw-4.17.0 — emergent-observation design meta-pattern #160 (Emergent-observation design meta-pattern; `fw-4.17.0` — this issue's parent context)
• RFC/tracking: cross-Charter knowledge layer (Cubeta B from #150 + #146 Proposal D) — post-announcement Charter #153 (Cross-Charter knowledge layer — `lessons-learned` index + `spec-drift` CLI; sibling RFC with the same scope-defining shape)

Filed post-merge of PR #160 to preserve the four-axes inventory across release cycles.