6.4 KiB
6.4 KiB
Research: Governance Operator Outcome Compression
Decision 1: Keep ArtifactTruthPresenter as the canonical truth seam and add compression only as a derived prominence layer
- Decision: Reuse
ArtifactTruthPresenterandArtifactTruthEnvelopeas the single canonical truth source for covered governance artifacts and add compression only as a downstream presentation step. - Rationale: The repo already has the correct multi-dimensional truth model for baseline snapshots, evidence snapshots, tenant reviews, review packs, and artifact-oriented operation runs. The problem is not missing truth, but that too many truth axes can still appear as equal first-class UI signals on operator surfaces. A derived compression layer can solve that without creating a second semantic source of truth.
- Alternatives considered:
- Add a new persisted
compressed_stateoroperator_outcomefield. Rejected because the state is fully derivable from the existing envelope and persistence would create drift risk. - Push all compression logic into individual Filament resources and pages. Rejected because the same prominence rules must stay consistent across multiple surfaces.
- Add a new persisted
Decision 2: Surface-family context must decide which truth dimension becomes primary
- Decision: Treat compression as context-aware by surface family instead of globally flattening every artifact into one universal operator statement.
- Rationale: Baseline and evidence surfaces primarily answer whether an artifact is usable or trustworthy now. Tenant review and review-pack surfaces primarily answer whether the artifact is publishable or safe to share. Review register and evidence overview remain queue-like summaries of those same questions, while run detail remains tertiary evidence. The compression layer must preserve those different operator questions.
- Alternatives considered:
- Make freshness or trustworthiness universally primary on every covered surface. Rejected because it would weaken publication clarity on reviews and packs.
- Make publication readiness primary everywhere. Rejected because it is not the first business question on baseline or evidence artifact surfaces.
Decision 3: Reuse OperatorExplanationBuilder, BadgeCatalog, and the current governance truth partial instead of inventing a second UI semantics framework
- Decision: Build compressed outcomes out of the existing explanation and badge vocabulary, then render them through the current shared detail/table family.
- Rationale: The repo already centralizes operator explanation patterns and badge semantics. Reusing them keeps the change aligned with BADGE-001, UI-FIL-001, and the few-layers rules. The right move is to decide prominence and grouping, not to invent new page-local labels, colors, or wrappers.
- Alternatives considered:
- Build a new
GovernanceOutcomeBadgeSystemor a separate explanation taxonomy. Rejected because it would duplicate the same semantics the repo already centralizes. - Replace the current truth partial with page-specific custom markup everywhere. Rejected because it would scatter the same visual language problem across multiple surfaces.
- Build a new
Decision 4: Diagnostics must be demoted, not deleted
- Decision: Preserve raw reason structures, supporting badge domains, diagnostics summaries, JSON context, and audit-visible truth, but move them behind the compressed primary summary.
- Rationale: The product's operator-truth promise depends on deep proof still being available. The problem is default prominence, not the existence of diagnostic detail. Compression should make the first read calmer without making troubleshooting weaker.
- Alternatives considered:
- Remove secondary truth dimensions entirely from touched surfaces. Rejected because it would sacrifice the proof operators and auditors still need.
- Leave all truth dimensions visible and just rename them. Rejected because scanability would remain poor.
Decision 5: Artifact-oriented run detail must reuse the same decision direction as the linked artifact
- Decision:
OperationRundetail for baseline/evidence/review/review-pack truth must present the dominant artifact impact and next action using the same compressed direction used on the linked artifact surface. - Rationale: The code already lets
ArtifactTruthPresenterderive envelopes forOperationRunand related artifacts. If run detail invents a different first-class message than the artifact list/detail surface, the operator will see contradictory language after drill-through. - Alternatives considered:
- Keep run detail on its current raw-truth hierarchy and treat it as fully independent. Rejected because the spec explicitly includes artifact-oriented run detail as an adoption surface.
- Create a separate run-detail-only compression system. Rejected because it would duplicate the same decision mapping problem.
Decision 6: Request-scoped caching must remain surface-context-safe
- Decision: If a new compression helper or memoized result is introduced, its cache key must include the surface-family context.
- Rationale: The current truth presenter already uses request-scoped derived-state caching. Compression adds a new dimension: the same underlying artifact can be summarized differently on baseline/evidence versus review/pack surfaces. Cache keys must distinguish those contexts so compressed outcomes do not bleed across surfaces in the same request.
- Alternatives considered:
- Recompute compression on every render path without caching. Rejected as unnecessary churn if the logic becomes shared.
- Reuse the current truth cache entry as-is. Rejected because the compression output is context-dependent even when the truth envelope is not.
Decision 7: Extend current Pest suites and fixtures instead of creating a new test harness
- Decision: Reuse
BuildsGovernanceArtifactTruthFixturesand extend the existing evidence, review, review-pack, register, overview, and run-detail test suites. - Rationale: The repo already has the right test families around the affected surfaces and a shared fixture concern for governance artifact truth states. The missing proof is cross-surface prominence and agreement, not a lack of testing infrastructure.
- Alternatives considered:
- Rely primarily on browser tests. Rejected because the change is already well-covered by current page/resource suites and browser breadth would be excessive.
- Add a separate UI compression harness. Rejected because it would create more maintenance cost than product certainty.