# Editorial Insight

A maturity insight report for trend interpretation and point-of-view writing.
It uses a maturity frame to explain why a trend, tension, or shift matters and
how leaders should think about it.

## Reference Mood

Harvard Business Review / MIT Sloan / point-of-view industry reports / data
journalism. Build a clear thesis through a small set of evidence and examples,
then end with implications.

The reading experience should feel closer to an opinion essay than a scorecard or operating dashboard.

## When To Use

- Internal evangelism, industry perspective pieces, trend briefings, and strategic discussion materials.
- Explanations of maturity shifts, trends, cases, comparisons, key observations, or organizational behavior signals.
- Turning assessment results into a more narrative, argument-led article.
- Situations where readers need to understand "why this matters" rather than immediately execute remediation.

## Information Architecture

- Start with a thesis, then develop the why and the evidence.
- The argument should contain a real-world tension, not just summarize the data.
- Use few evidence points, but make them precise; use cases to make abstract judgments concrete.
- End with implications, not a task checklist.

## Structure Pattern

1. Opening thesis: state the core point and real-world tension in one sentence.
2. Why it matters: explain the impact on business, engineering, governance, or the organization.
3. Maturity shift: describe how maturity has moved from past to present to future.
4. Evidence: support the argument with key data, scan signals, or observations.
5. Case vignette: make the point concrete through a team, project, or scenario.
6. Framework: extract a reusable explanatory frame.
7. Implications: give directional guidance for leaders, architects, platform teams, or governance teams.

## Visual Language

- Thesis-led, paced like a narrative, and evidence-backed without becoming promotional.
- Works well with a hero thesis, annotated chart, stage transition, case card, pull quote, and implication cards.
- Use a small number of sharp charts that serve the argument rather than piling on data.
- Use cases to carry abstract ideas, not to become full case studies.
- White space and section rhythm matter more than information density.

## Visualization Style

- Primary visualization family: one focused proof chart that supports the
  thesis; use a trend, comparison, or small-share chart according to the
  evidence shape.
- The findings section should pair the proof with compact evidence rows so
  readers can see what the thesis is based on.
- Supporting visualization blocks: narrative interpretation, compact evidence
  table, and implication cards or narrative blocks. Use only a few proof points.
- Preserve enough concrete evidence anchors in visual companion rows or adjacent
  evidence blocks for readers to audit the claim. Do not compress important
  evidence into opaque aliases such as `r9/r10/...` when the Markdown names
  specific artifacts, review files, commands, or screenshot paths.
- Label trend charts as draft, cumulative, sampled, or reviewed according to
  what the data actually means. Do not label a point `reviewed` or `passed`
  until that review or pass exists in the evidence boundary.
- Prefer implication cards or narrative blocks over wide multi-column
  implication tables so the visual companion remains readable on mobile.
- Do not turn the visual companion into an audit scorecard, dashboard, or remediation
  tracker.

## Content Granularity

- The opening thesis should be short and strong, not a summary paragraph.
- Evidence should highlight at most three critical proof points.
- A case vignette should read like a short scene, not a project retrospective.
- Implications should set direction, not become a 30/60/90 execution plan.

## Boundaries

- Do not write a generic white paper summary.
- Do not exaggerate what the data supports for the sake of the narrative.
- Do not turn this into an audit scorecard, operating dashboard, or detailed transformation manual.
- If evidence or cases are missing, mark them as `[needs validation]` or `[example scenario]`.