Date every page against the release it was true of, run the code examples rather than proofread them, and hold each revision for the named owner who publishes it.
A page is published, and the release it was true of is recorded against it.
02
A claim is made about a security control, and the evidence that would back it is named beside it.
Reason
03
A code example is executed against the release it claims to describe, rather than read for sense.
04
A runbook command is run on a schedule, so a command that no longer exists surfaces before it is needed.
05
A method is renamed, and each page whose example calls it by the old name is listed for revision.
Decide
06
A sunset date is drafted, and the notice period the contract promises is checked against it.
07
A regulated instruction set keeps each superseded version published, under Regulation (EU) 2021/2226.
Out
08
A page passes its currency term unrevised, and it is marked unverified rather than left standing.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Drafting, dating and flagging belong to the agent. Publication belongs to a named documentation owner, who holds editorial responsibility for the page and answers for it once it is live.
2Sources assembledThe diff, the release it lands in, the pages that cite it and the evidence each claim rests on
3Page drafted and datedThe revision, the release it is dated to, the claims flagged for review and confidence
4Controls appliedExample execution, claim-to-evidence checks, notice-date checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is published at any of them — the agent is drafting, and the owner lane opens at the publication gate.
5DecisionSplits at the publication gate
Evidence complete
Goes to the named owner to publish.
Anything unevidenced
Adds a subject-matter read first.
Owner publication
The page is held with its evidence, its flagged claims and what the controls returned.
Publish · Revise · Send to subject-matter review
Published — by the named owner▼
6Documentation and site records updatedOnly where write access and publishing policy allow it
7Outcome evaluatedClaim currency, example failures, owner corrections and what readers reported after publication
Corrections
Each owner correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Publishing any page to a customer-facing site.
Drafting a customer incident notice.
Asserting that a security control is in place.
Setting the end-date of a support period.
Automation boundaryAgent acts unaided
✓Date each page against the release it describes.
✓Execute the code examples a page publishes against that release.
✓Name the control that would evidence a claim on a security page.
✓Mark a page unverified once its evidence goes stale.
Nothing reaches a published page except by a named owner, inside the agreed boundaries.
Signing a regulated technical file or a submission.
Deciding that a deprecation notice has been given.
Holding editorial responsibility for a published page.
Changes to publishing rules or currency thresholds.
Example output
One page, annotated
An SOP agent writes the procedures a floor runs on; this one writes what a developer reads and what a regulator later quotes back. Below is one page as the agent leaves it.
Documentation output · single pageIllustrative example
Page
Recorded as
Release
Evidence of record
Confidence
Held for
Authentication reference page
Rate limits described, examples executed
Dated to release
Release record, 3 August 2026
Held unpublished
The named owner, by name
As receivedTaken from the source tree and the release record — the agent vouches for the date, not the design.
What the record holdsSource diffExecuted exampleRelease record
Why no publication herePublishing a page is a representation the named owner makes and owns.
ActionPublishReviseSend to subject-matter review
What the score decidesBelow the configured threshold a page gets a subject-matter read before the owner sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each pageFrom the change that moved it
03Evidence
Where the evidence is used
The same sentence is an engineering aid to a developer, a representation to a regulator and a description a buyer can hold you to; what changes with the reader is who can sue.
01Approved path
True when it was written
One public security statement was described by an employee as aspirational; a page can also decay honestly, because a rename seldom triggers a documentation update.
02Human review
What was checked, and not found
No enforcement action consulted turned on a page nobody wrote. Blackbaud was charged over statements it chose to publish and over one incident notice charged twice, as unfair and as deceptive, and it settled without admitting or denying. The Cyber Resilience Act does not bite until December 2027.
04Build an evidence trail
The sentence, the code it describes and the owner who published it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Source and schemasGitHub · GitLab · Bitbucket OpenAPI and protobuf schemas
A set-level currency figure can read clean while security and trust pages carry most of the corrections. Nestack reports the correction rate by page class and by release, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Security and trust pages
11.7%
3.7×
Review
Runbooks and on-call steps
8.3%
2.6×
Review
Deprecation and release notes
5.2%
1.6×
Watch
Settled reference pages
2.6%
0.8×
Normal
Bar: correction-rate lift vs. settled-reference baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What the security page still claimed
A cycle shuts when the promise no release still keeps is a regression case. That suite is what the next page published is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on security and trust pages.
02Diagnose
The security page that was true at the last audit and has been a representation ever since is read back against the controls it names until one cause is left standing.
03Improve
Changes ship numbered, and the pages behind them travel attached.
04Verify
Each touched page case is run again, and one red holds it back.
05Learn
The case is kept, and the publishing rules are amended in that same commit.
Learn → DetectThe return edge. The next page published is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, publishing workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Doc-set discovery and automation-boundary definition.
02Source, schema and platform assessment.
03Claim-evidence and documentation-policy rule mapping.
04Change and schema ingestion.
05Claim binding and drafting logic.
06Confidence scoring and review routing.
07Owner publication workflow.
08Documentation-platform integration.
09Currency and claim cases.
10Guardrails and publishing controls.
11Page-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne doc set, one release trainProductionProduction publishing workflowAdvancedMultiple doc sets / audiences
Introduced at Pilot
Drafting and dating to your release records✓✓✓
Named owner publication✓✓✓
Document-inventory baseline✓✓✓
Introduced at Production
Reporting by page class—✓✓
Subject-matter review workflow in your systems—✓✓
Approved publishing write-back—✓✓
Repository-and-site integration—✓✓
Introduced at Advanced
Multi-language doc sets——✓
Cross-audience publishing packs——✓
Large documentation estates——✓
Multi-audience publishing controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, page volume, publishing controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live doc sets and the release each one is dated to→Page capture and release-date versioningWeek 1
02Representative pages, schemas and runbooks→Source binding, claim logic and the currency baselineWeek 2
03Your publishing calendar and the owners it names→Claim-evidence mapping, page binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Repository, schema and platform assessment, then integration setupWeek 2
05Pages you would not want quoted back→Currency cases and the evaluation roundWeek 4
06What no page may promise→Confidence scoring, review routing, guardrails and publishing controlsWeek 3
07A named owner who publishes the page→Release to the named owner, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
A band here is as wide as the phase costs, so the fifth week shows a pair and not a tidier blank.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Documentation discovery, publishing rules and the automation boundaryW2Repository and platform integration and the document-inventory baselineW3Claim binding, drafting logic and publishing controlsW4Evaluation suite, currency cases and failure-mode testingW5Platform integration, pilot pages and targeted correctionsW6One publishing cycle run under the documentation owner, then Agent Care handover
Reading the bandEach band covers only the weeks its own work is named for, and the fifth week is shared by design.
At the end of W6Once the page record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a documentation agent around the page your last release never revised.
Silence carries no legal risk, and each true sentence you publish carries a standing obligation to remain true. Show us your security page and the release it was written for. The only defensible position left is documentation that is maintained.
