Add changelog and origin docs

Author: mizcausevic-dev

CHANGELOG.md

@@ -12,7 +12,8 @@ This log is intentionally written as an engineering record rather than a launch
 - Tightened the repo story around the real-world operating problem: answer-engine visibility gaps, weak semantic packaging, and inconsistent structured-data coverage.
 
 ### Why this mattered
-- Existing approaches in SEO crawlers, analytics dashboards, and structured-data validators were useful, but they were good at web hygiene, but weak at modeling the citation and semantic packaging needs of answer engines.
+- Existing approaches in SEO crawlers, analytics dashboards, and structured-data validators were useful for adjacent workflows.
+- They still missed the core need: a way to connect web hygiene with citation readiness, semantic packaging, and answer-engine discoverability.
 - This release made the repo readable as an operational capability rather than a narrow technical demo.
 
 ## [0.1.0] - 2026-01-20

docs/ORIGIN.md

@@ -1,12 +1,12 @@
 # Why We Built This
 
-**aeo-sdk-python** 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.
+**aeo-sdk-python** came out of repeated work around answer-engine visibility. The pattern was consistent: systems were getting more capable faster than the operating models used to review, govern, and steer them. Teams could collect raw signals, but still struggle to answer the harder questions under pressure: what is actually drifting, who owns the next move, and how much business or control risk is building underneath the technical state.
 
 In this case the pressure showed up around answer-engine visibility gaps, weak semantic packaging, and inconsistent structured-data coverage. 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 **aeo-sdk-python**. 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 answer-engine visibility 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 growth, search, and content operations teams.
 
-Existing tools missed the mark for reasons that were understandable. SEO crawlers, analytics dashboards, and structured-data validators each solve a meaningful piece of the problem. But they were good at web hygiene, but weak at modeling the citation and semantic packaging needs of answer engines. 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.
+Existing tools missed the mark for understandable reasons. The available tooling landscape — SEO crawlers, analytics dashboards, and structured-data validators — helped with record-keeping, scanning, reporting, or workflow coverage. What it still missed was a way to connect web hygiene with citation readiness, semantic packaging, and answer-engine discoverability. 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.
 
 That shaped the design philosophy from the start: