Working AtlasDocumentation automation

Change-to-Docs Review Gate

Trace a merged change into a human-reviewable documentation draft.

TryCompare “API change · docs impact” with “Generated-only change.” Then switch back and inject a validator failure.

Watch forAPI updates reach human review; generated-only changes stop at the relevance check.

Jump to the model
Separate teaching model

The linked story describes related work; the scenarios and results here are synthetic.

Interactive model

Preparing the interactive experiment…

Skill practicedDesign review gates for change-driven automation

Connection to my workMy Docs Agent work includes its filter, validator, and verifier workflow. This separate model lets you test those review decisions with synthetic changes.

Related story:Docs Agent at Setu →

Understand the result

A synthetic merged change moves through a scope filter, validation, verification, and a reviewable proposal. Select an irrelevant change or inject a gate failure to see where the flow stops. A successful run ends with a draft for human review; it never publishes automatically and does not reproduce the Docs Agent service.

Controls

Change scenario
Choose a synthetic documentation-bearing change, generated-only change, or change missing merge context.
Inject validator failure
Make the synthetic validation gate fail after a change passes the scope filter.
Inject verification mismatch
Make a later synthetic verifier find a mismatch between the draft and source facts.

What to watch for

  • API change · docs impact reaches human review; generated-only changes stop at the relevance check.
  • Choose Generated-only change. The scope filter stops the flow before validation begins.
  • Inject a validator failure. Verification and proposal remain unreached.
  • Restore the validator, inject a verification mismatch, and see the flow stop before a draft is offered for review.

Why it happens

Automating a proposal does not require automating publication. A relevance filter can avoid unnecessary work, validators can reject unsuitable inputs, and a verifier can check a draft against its source before a person reviews it. The real workflow description supports those broad stages and the review boundary; this small simulation invents its own cases and behavior for teaching purposes.

How this idea relates to the linked work

The Docs Agent story describes a workflow that examines merged GitLab changes, applies filter, validator, and verifier stages, and proposes documentation updates through reviewable merge requests. This independent exercise makes that review discipline inspectable with synthetic cases. It does not reproduce the service architecture, production checks, or measured accuracy.

See the broader engineering brief