197 lines
8.1 KiB
Markdown
197 lines
8.1 KiB
Markdown
# Data Model: Humanized Diagnostic Summaries for Governance Operations
|
|
|
|
## Overview
|
|
|
|
This feature does not add or modify persisted domain entities. It adds a logical derived presentation model for canonical governance operation run detail under `/admin/operations/{run}`.
|
|
|
|
The design constraint is strict:
|
|
|
|
- `OperationRun` remains the only persisted source for run lifecycle and execution truth.
|
|
- Related artifacts such as `BaselineSnapshot`, `EvidenceSnapshot`, `TenantReview`, and `ReviewPack` remain the persisted source for artifact truth where they exist.
|
|
- `ArtifactTruthPresenter`, `OperatorExplanationBuilder`, and `ReasonPresenter` remain the semantic inputs.
|
|
- The new summary remains fully derived and surface-specific.
|
|
|
|
## Existing Persistent Inputs
|
|
|
|
### 1. OperationRun
|
|
|
|
- Purpose: Canonical operational record for background and governance work.
|
|
- Key persisted fields used by this feature:
|
|
- `id`
|
|
- `workspace_id`
|
|
- `tenant_id`
|
|
- `type`
|
|
- `status`
|
|
- `outcome`
|
|
- `context`
|
|
- `summary_counts`
|
|
- `failure_summary`
|
|
- `started_at`
|
|
- `completed_at`
|
|
- Relationships and derived lookups used by this feature:
|
|
- workspace and tenant context
|
|
- related artifact resolution through current operation catalog and presenter logic
|
|
|
|
### 2. Related Governance Artifacts
|
|
|
|
These are not newly modeled by this feature, but they remain relevant when a run produced or references an artifact.
|
|
|
|
- `BaselineSnapshot`
|
|
- `EvidenceSnapshot`
|
|
- `TenantReview`
|
|
- `ReviewPack`
|
|
|
|
The feature only reads their already-derived truth where available.
|
|
|
|
## Existing Derived Inputs
|
|
|
|
### A. ArtifactTruthEnvelope
|
|
|
|
`ArtifactTruthPresenter` already derives `ArtifactTruthEnvelope` for `OperationRun` and related artifact records.
|
|
|
|
Important envelope dimensions already available:
|
|
|
|
- `artifactExistence`
|
|
- `contentState`
|
|
- `freshnessState`
|
|
- `publicationReadiness`
|
|
- `supportState`
|
|
- `actionability`
|
|
- `primaryLabel`
|
|
- `primaryExplanation`
|
|
- `reason`
|
|
- `diagnosticLabel`
|
|
|
|
This feature must consume that envelope instead of replacing it.
|
|
|
|
### B. OperatorExplanationPattern
|
|
|
|
`OperatorExplanationBuilder` already derives an explanation pattern containing:
|
|
|
|
- `headline`
|
|
- `evaluationResult`
|
|
- `executionOutcome`
|
|
- `trustworthinessLevel`
|
|
- `reliabilityStatement`
|
|
- `coverageStatement`
|
|
- `dominantCauseCode`
|
|
- `dominantCauseLabel`
|
|
- `dominantCauseExplanation`
|
|
- `nextActionCategory`
|
|
- `nextActionText`
|
|
- `countDescriptors`
|
|
|
|
This feature reuses that pattern as input to the new run-detail summary.
|
|
|
|
## Derived Presentation Entities
|
|
|
|
### 1. GovernanceRunDiagnosticSummary
|
|
|
|
Primary derived object for canonical run detail.
|
|
|
|
| Field | Meaning | Source |
|
|
|---|---|---|
|
|
| `headline` | One dominant first-pass statement for the run detail page | derived from `ArtifactTruthEnvelope` + `OperatorExplanationPattern` |
|
|
| `executionOutcomeLabel` | Technical execution result kept visible as a separate fact | `OperationRun.outcome` via existing badge semantics |
|
|
| `artifactImpactLabel` | What the resulting artifact means for operator action | artifact truth + explanation pattern |
|
|
| `primaryReason` | One short reason supporting the headline | dominant cause explanation or primary explanation |
|
|
| `affectedScaleCue` | One operator-readable scale cue, such as ambiguous subjects or missing sections | `summary_counts`, run `context`, or related artifact truth |
|
|
| `nextActionText` | First follow-up step the operator should see | existing explanation or next-step logic |
|
|
| `secondaryCauses[]` | Additional contributing causes preserved below the primary cause | ranked from reason/context inputs |
|
|
| `diagnosticsAvailable` | Whether deeper technical sections still exist below | derived from reason, payload, or technical sections |
|
|
|
|
Validation rules:
|
|
|
|
- Exactly one `headline` is allowed for the default-visible summary.
|
|
- `artifactImpactLabel` must stay distinct from `executionOutcomeLabel`.
|
|
- `affectedScaleCue` is optional, but when present it must be backed by numeric or enumerated persisted evidence, not freeform guesswork.
|
|
- `secondaryCauses[]` must not repeat the dominant cause.
|
|
|
|
### 2. DominantCauseBreakdown
|
|
|
|
Logical grouping of the main and supporting causes for degraded runs.
|
|
|
|
| Field | Meaning |
|
|
|---|---|
|
|
| `primaryCauseCode` | Stable internal reason or derived cause key |
|
|
| `primaryCauseLabel` | Operator-facing dominant cause label |
|
|
| `primaryCauseExplanation` | Short explanation shown in the summary area |
|
|
| `secondaryCauses[]` | Additional causes shown in supporting detail only |
|
|
| `rankingRule` | Stable ranking rule used to keep ordering deterministic |
|
|
|
|
Rules:
|
|
|
|
- Ranking must be deterministic for equivalent runs.
|
|
- The same cause class must keep the same reading direction across covered governance families.
|
|
- A run with no meaningful secondary cause data may omit the secondary list entirely.
|
|
|
|
### 3. AffectedScaleCue
|
|
|
|
Small derived object explaining what was affected and at what scale.
|
|
|
|
| Field | Meaning |
|
|
|---|---|
|
|
| `label` | Operator-facing scale label such as `Affected subjects`, `Missing sections`, or `Incomplete dimensions` |
|
|
| `value` | Human-readable count or scale statement |
|
|
| `source` | Where the cue came from: `summary_counts`, `context`, or related artifact truth |
|
|
| `confidence` | Whether the cue is exact, bounded, or best available from persisted context |
|
|
|
|
Rules:
|
|
|
|
- This object remains optional because not every run family has equally rich scale data.
|
|
- It must never introduce a new persisted count contract.
|
|
- It must not imply precision the persisted data does not support.
|
|
|
|
### 4. GovernanceRunSummaryContext
|
|
|
|
Logical context for the summary builder.
|
|
|
|
| Field | Meaning |
|
|
|---|---|
|
|
| `surface` | Always `canonical_operation_run_detail` for this spec |
|
|
| `canonicalOperationType` | Canonical operation type from `OperationCatalog` |
|
|
| `artifactFamily` | Related artifact family when one exists |
|
|
| `tenantVisibility` | Whether related tenant/artifact context is visible to the current actor |
|
|
|
|
Rules:
|
|
|
|
- This context is surface-specific and must not become a cross-product taxonomy.
|
|
- Tenant visibility rules must suppress inaccessible related labels and links.
|
|
|
|
## Covered Run Families
|
|
|
|
| Canonical Type | Primary Artifact Family | Typical Affected-Scale Source | Dominant-Cause Focus |
|
|
|---|---|---|---|
|
|
| `baseline.capture` | `baseline_snapshot` | `summary_counts`, `context.result`, baseline snapshot summary | blocked prerequisite, zero in-scope subjects, unusable snapshot result |
|
|
| `baseline.compare` | none direct, but linked baseline/evidence truth may exist | `summary_counts`, `context.baseline_compare`, evidence-gap payloads | suppressed output, ambiguous matches, evidence gaps, strategy failure |
|
|
| `tenant.evidence.snapshot.generate` | `evidence_snapshot` | evidence snapshot summary, completeness state, run counts | stale or incomplete evidence basis, blocked snapshot generation |
|
|
| `tenant.review.compose` | `tenant_review` | review summary, missing sections, related evidence truth | missing sections, stale evidence, internal-only review outcome |
|
|
| `tenant.review_pack.generate` | `review_pack` | pack summary, linked review state, generation context | internal-only or blocked pack outcome, source-review limitations |
|
|
|
|
## Derivation Rules
|
|
|
|
### Summary selection order
|
|
|
|
1. Resolve canonical operation type.
|
|
2. Resolve related artifact truth if present.
|
|
3. Resolve operator explanation pattern.
|
|
4. Derive dominant cause and supporting causes.
|
|
5. Derive affected-scale cue from existing persisted data.
|
|
6. Build one `GovernanceRunDiagnosticSummary`.
|
|
7. Render diagnostics below that summary without altering the underlying truth.
|
|
|
|
### Zero-output runs
|
|
|
|
- If a run completed technically but produced no decision-grade artifact, the summary must explicitly say so.
|
|
- Zero output must never default to a neutral or green reading.
|
|
|
|
### Multi-cause degraded runs
|
|
|
|
- One primary cause is required.
|
|
- Additional causes remain visible as supporting detail only.
|
|
- The ranking rule must be deterministic and shared across all covered run families.
|
|
|
|
### Authorization-sensitive output
|
|
|
|
- Related artifact names, tenant names, and links may only appear when entitlement checks already pass.
|
|
- The summary may remain useful without those labels by using generic operator-safe phrasing. |