Add changelog and origin docs

Author: mizcausevic-dev

CHANGELOG.md

@@ -4,12 +4,12 @@ All notable changes to this project are documented here.
 
 This log is intentionally written as an engineering record rather than a launch theater timeline. Dates reflect when the concept, design, prototype, and public packaging phases were mature enough to document.
 
-## [1.0.0] - 2026-05-06
+## [1.0.0] - 2026-05-12
 
 ### Released
-- Published \$name\ as a public, portfolio-grade platform governance system.
+- Published **content-workflow-intelligence-platform** as a public, portfolio-grade platform governance system.
 - Packaged the current implementation, documentation, validation workflow, and proof surfaces into a repo that could be reviewed by engineering, product, and operating stakeholders.
-- Tightened the repo story around the real-world operating problem: operators needed clearer evidence when policy drift, incident pressure, or observability cost moved from a technical nuisance into a business risk.
+- Tightened the repo story around the real-world operating problem: policy drift, observability blind spots, latency pressure, and fragmented control evidence.
 
 ### Why this mattered
 - Existing approaches in monitoring, SIEM, CI, and governance tools were useful, but they each solved a slice of the problem, but not the combined operator view needed to respond with confidence.
@@ -18,7 +18,7 @@ This log is intentionally written as an engineering record rather than a launch
 ## [0.1.0] - 2026-02-20
 
 ### Shipped
-- Cut the first coherent internal version of the product shape behind \$name\.
+- Cut the first coherent internal version of the product shape behind **content-workflow-intelligence-platform**.
 - Standardized the core objects, decision surfaces, and operator outputs around the repo's main working problem.
 - Established the first reviewable version of the architecture described as: TypeScript platform for editorial workflow intelligence, publishing readiness scoring, bottleneck visibility, and content operations governance.
 
@@ -55,12 +55,12 @@ This log is intentionally written as an engineering record rather than a launch
 ## [Idea Origin] - 2023-02-08
 
 ### Observed
-- The initial idea surfaced while looking at how teams were handling operators needed clearer evidence when policy drift, incident pressure, or observability cost moved from a technical nuisance into a business risk.
+- The initial idea surfaced while looking at how teams were handling policy drift, observability blind spots, latency pressure, and fragmented control evidence.
 - The recurring pattern was that people could often see fragments of the problem, but not the whole operational story in one place.
 
 ### Insight
 - The missing product was not another point solution. It was a clearer operating layer that made the work legible to platform, security, and reliability teams.
-- That insight became the basis for \$name\.
+- That insight became the basis for **content-workflow-intelligence-platform**.
 
 ## [Background Signals] - 2022-08-09
 

docs/ORIGIN.md

@@ -1,10 +1,10 @@
 # Why We Built This
 
-\$name\ grew out of a pattern that kept repeating in enterprise software work: the surface area of modern systems was expanding faster than the operational models teams used to govern them. The tools themselves were getting more capable. The workflows around them were not. In practice, that meant teams could often collect raw signals, but still struggle to answer the harder questions: what is actually drifting, who owns the next move, and what kind of business or control risk is building underneath the technical state.
+**content-workflow-intelligence-platform** grew out of a pattern that kept repeating in enterprise software work: the surface area of modern systems was expanding faster than the operational models teams used to govern them. The tools themselves were getting more capable. The workflows around them were not. In practice, that meant teams could often collect raw signals, but still struggle to answer the harder questions: what is actually drifting, who owns the next move, and what kind of business or control risk is building underneath the technical state.
 
-In this case the pressure showed up around operators needed clearer evidence when policy drift, incident pressure, or observability cost moved from a technical nuisance into a business risk. That sounds specific, but the underlying failure mode was familiar. A team would have multiple tools in place, each doing a piece of the job. There might be observability, validation, ticketing, dashboards, static analysis, workflow software, or spreadsheet-based reporting. None of that meant the operating problem was actually solved. What was usually missing was a clear translation layer between system behavior and accountable action.
+In this case the pressure showed up around policy drift, observability blind spots, latency pressure, and fragmented control evidence. That sounds specific, but the underlying failure mode was familiar. A team would have multiple tools in place, each doing a piece of the job. There might be observability, validation, ticketing, dashboards, static analysis, workflow software, or spreadsheet-based reporting. None of that meant the operating problem was actually solved. What was usually missing was a clear translation layer between system behavior and accountable action.
 
-That was the opening for \$name\. The repo was designed around a simple idea: operators need more than visibility. They need evidence, priorities, and next actions that make sense under pressure. That is why the project is framed as platform governance rather than as a generic app demo. The point is not just to show that data can be rendered or APIs can be wired together. The point is to show what a practical control surface looks like when the audience is platform, security, and reliability teams.
+That was the opening for **content-workflow-intelligence-platform**. The repo was designed around a simple idea: operators need more than visibility. They need evidence, priorities, and next actions that make sense under pressure. That is why the project is framed as platform governance rather than as a generic app demo. The point is not just to show that data can be rendered or APIs can be wired together. The point is to show what a practical control surface looks like when the audience is platform, security, and reliability teams.
 
 Existing tools missed the mark for reasons that were understandable. monitoring, SIEM, CI, and governance tools each solve a meaningful piece of the problem. But they each solved a slice of the problem, but not the combined operator view needed to respond with confidence. In other words, the gap was not capability in isolation. The gap was operational coherence. The team responsible for day-to-day decisions still had to reconstruct the story manually.
 
@@ -14,6 +14,6 @@ That shaped the design philosophy from the start:
 - **decision-legible** so a security lead, platform operator, product owner, or business stakeholder can understand why a recommendation exists
 - **CI-native** so the checks and narratives can live close to where systems are built, changed, and reviewed
 
-That philosophy also explains what this repo does not try to be. It is not a vague “AI platform,” not a one-off research prototype, and not a thin wrapper around a fashionable stack. It is a targeted attempt to model a real operating layer around this problem: TypeScript platform for editorial workflow intelligence, publishing readiness scoring, bottleneck visibility, and content operations governance.
+That philosophy also explains what this repo does not try to be. It is not a vague "AI platform," not a one-off research prototype, and not a thin wrapper around a fashionable stack. It is a targeted attempt to model a real operating layer around this problem: TypeScript platform for editorial workflow intelligence, publishing readiness scoring, bottleneck visibility, and content operations governance.
 
-What comes next is practical. The roadmap is about pushing the project deeper into real operational utility: historical baselines, export adapters, stronger policy authoring, and richer fleet-level visibility. That direction matters because the long-term value of \$name\ is not the individual screen or endpoint. It is the operating discipline behind it. The repo exists to show how a messy modern problem can be turned into something reviewable, governable, and usable by real teams.
+What comes next is practical. The roadmap is about pushing the project deeper into real operational utility: historical baselines, export adapters, stronger policy authoring, and richer fleet-level visibility. That direction matters because the long-term value of **content-workflow-intelligence-platform** is not the individual screen or endpoint. It is the operating discipline behind it. The repo exists to show how a messy modern problem can be turned into something reviewable, governable, and usable by real teams.