Content QA-as-Code Starts When Review Decisions Become Loadable
Content QA-as-Code turns review findings, decisions, rules, and exports into loadable memory for the next draft, reviewer, agent, or check.
The repo looks disciplined. The content lives in Markdown. The style guide is in Git. An AI agent can draft the next page before lunch. A reviewer still opens the draft and finds the same unsupported claim they rejected last week.
The linter didn’t miss a comma. The workflow missed the reason.
Content QA-as-Code means editorial standards and review decisions become structured artifacts that future reviews, agents, and checks can load. It is not only a style guide in Git. It also doesn’t mean every editorial judgment becomes an automated CI block.
The code-like part is the reusable reason behind the review: what was found, where it was found, why it mattered, what the reviewer decided, and whether the same standard should become a rule or export.
The existing layer is real
Content and docs teams already have serious code-like tools.
Docs-as-code gives documentation teams familiar software workflows: Git, plain-text markup, review, issue tracking, and automated tests. Vale can run custom prose rules. markdownlint can check Markdown structure and consistency. GitHub Actions can run YAML-defined workflows made of jobs. Open Policy Agent can run policy-as-code guardrails in CI/CD pipelines.
That layer matters. Banned phrases, missing metadata, broken Markdown, heading depth, required fields, and known terminology can be checked deterministically.
But deterministic checks mostly answer a narrower question: did this artifact match a rule that already exists in a machine-readable form?
Editorial review often starts before that rule exists. A reviewer notices a risky claim, weak source, misleading comparison, stale CTA, or tone problem that the current rule file did not name. If the decision stays in a resolved comment or Slack thread, the next workflow starts cold.
The reusable reason has to outlive the comment
A style guide can say, “Do not make unsupported compliance claims.” That helps. It still leaves the hard work to the reviewer when a draft says, “This process ensures compliance.”
Content QA-as-Code begins when the review produces a loadable record:
- reviewed content version
- anchored finding
- issue type or severity
- source or evidence context
- decision
- rationale
- rule candidate or live rule reference
- schema-versioned export metadata
That record is different from a comment. A comment helps the current writer. A structured finding can help the next reviewer, the next agent, and the next check.
The point is not to turn every review note into permanent law. Some notes are local. Some are rejected. Some become advisory context until a human promotes them. The artifact needs decision state for that reason. A future workflow should know whether it is loading an active rule, a pending suggestion, or a rejected idea that should stay out of the next draft. Without that, review history becomes another pile of ambiguous instructions.
It also separates approval from review. Approval says whether a draft can move forward. Review says what was found, why it mattered, and what standard should survive. If those feel blurry, the adjacent distinction is covered in Content Approval vs Content Review. This article is about the next step: making the review decision loadable.
The weak version of Content QA-as-Code stops too early. “Put the rules in the repo” is not enough if the workflow never checks output against those rules and never records what happened when the rule met a real draft.
CI consumes rules. Review creates them.
CI is good at known checks. It should run the linter, validate required fields, test exports, and reject artifacts that violate rules your team has already made explicit.
Review is where new judgment enters the system.
When a reviewer rejects a claim, they are not only changing a sentence. They are deciding that a standard matters. If that decision is repeated or important, it should become a rule, a rulepack entry, or an exportable finding that later work can inspect.
That distinction keeps the software analogy honest. CI can consume a rule. It cannot preserve editorial judgment that was never recorded. An agent can load a rulepack. It cannot inherit the reason behind a reviewer decision if the reason only lived in a comment thread.
Agents do not need vague memory. They need a loadable artifact with provenance: the last accepted rule, the source behind it, the block where the issue appeared, and the decision state that says whether the rule is live, pending, or rejected. Without that shape, “remember this for next time” becomes another instruction competing with every other instruction.
This is where structured feedback matters, and why the physical address of a finding belongs in block-level anchoring. The deeper lifecycle from repeated feedback into loadable standards belongs in rules to rulepacks. The narrow point here is earlier: a review decision has to become an artifact before later systems can reuse it.
Where Typescape fits
Typescape is the review layer for that artifact. It does not replace docs-as-code, CI, Vale, markdownlint, editors, or human judgment. It records review lifecycle state so judgment can survive the draft.
The product nouns are intentionally plain: review, finding, decision, rule, rulepack. A review is tied to content version context. A finding records the issue on a block. A decision records what happened and why. A rule captures reusable guidance. A rulepack or schema-versioned JSON export gives future humans, agents, or downstream checks something to load.
Humans and external agents still own semantic judgment. Typescape owns the structure around it: block-level anchoring, lifecycle state, provenance, rules, and exports. That boundary matters because Content QA-as-Code should not become another hidden model making silent editorial calls.
The one-review test
Pick the last important review note your team left.
Can another reviewer see the finding without reconstructing the whole conversation? Can an agent load the rule without reading a week of comments? Can the team tell whether the decision was accepted, rejected, or deferred? Can the source behind the decision be inspected?
If not, you may have content QA. You do not yet have Content QA-as-Code.
Content QA-as-Code is not CI theater. It is the discipline of making review judgment durable enough for the next draft, reviewer, agent, or check to use.
If your review notes disappear after each draft, start with one structured review. Typescape Free gives you 15 review sessions per month with block-level findings and schema-versioned JSON export, no credit card required.