The Documentation Agent
Documents go stale invisibly. Nothing about a work instruction changes when the part it describes revises, so the instruction stays confident and wrong until somebody notices on the floor.
Four staleness signals
Staleness is not one condition, and treating it as one produces either noise or silence. The agent watches four distinct signals and reports them differently.
- Referenced object revised — a work instruction naming a part that has since revised. Mechanical, high confidence, and by far the most common.
- Contradicted content — a document stating a value that disagrees with the typed characteristic it describes. A procedure saying *torque to 4 Nm* against a specification now saying 4.5.
- Orphaned reference — a document referencing an object that no longer exists in the state it assumes, such as a superseded controlled copy or a deleted draft.
- Age against change velocity — a document untouched for two years describing an assembly that has changed nine times. This is the weakest signal and is reported as a question rather than a finding.
What a draft correction is and is not
For the first two signals the agent produces a proposed edit: the specific text, the specific replacement, and the citation showing why. The proposal is a draft revision, not a published one.
It goes through the normal change process. A person reviews it, an approver approves it, and the document revises with the agent recorded as the drafter and the person recorded as the author of the decision. That attribution distinction is deliberate and it survives in the audit trail.
Where the agent cannot produce a confident correction it says so and reports the finding without a draft. A finding with no proposal is more useful than a proposal with no confidence, because the second costs a reviewer more time than writing it themselves would have.
It also does not touch content that is not verifiable against data. Rationale, background and design intent are not stale in a way software can detect, and the agent does not rewrite prose for style. A document edited by a machine for readability is a document whose author's voice has been quietly replaced.
The failure it prevents
An assembly procedure specifies a torque value. Three years later the fastener changes to a different thread pitch and the specification's torque characteristic updates. The procedure does not, because updating it was step nine of a change checklist and step nine got skipped.
Assembly continues at the old torque for seven months. The joints are within neither specification and pass visual inspection. The problem is found in a field return with a loosened fastener, and the containment covers everything built in that window.
Nothing in the system was wrong except the document, and nothing in the system was watching the document. The contradiction between *4 Nm* in a procedure and *4.5 Nm* on a characteristic is trivially detectable the day it appears — provided something is looking.
How it meets the rest of the product
It depends entirely on documents having relationships. A document attached to an item revision and referencing typed characteristics is analysable; a PDF in a folder is not, which is why the specifications-as-data and document-relationship work is a prerequisite rather than a companion.
Findings become tasks against the document owner, and where a finding relates to a change, it attaches to that change — so the documentation work appears as part of the change rather than as a separate queue that grows quietly.
Controlled copies are the reason urgency varies. A stale document with eleven outstanding controlled copies at three suppliers is a different problem from a stale internal draft, and the finding says which one it is rather than treating both as one severity.
Citations are how a finding gets checked in seconds rather than minutes. Each one names the document, the revision, the passage and the object it contradicts, so a reviewer confirms or dismisses it without opening two systems and reconstructing the comparison themselves.
How it meets your ERP
Documents referenced from your ERP — a specification on a purchase order line, a drawing on an item — are the ones where staleness reaches outside the building fastest, and the agent weights findings accordingly.
Where an ERP open-order read exists, a finding can state that a stale specification is referenced by four open purchase orders covering nine hundred units. That turns a documentation task into a scheduling decision with a number attached to it.
The agent does not write to your ERP or update a document reference there. Corrections happen here and reach the ERP through the ordinary publication path, because a document revision arriving by a side channel is a revision with no change record behind it.
Where the boundary is
It never publishes. Every correction is a draft revision entering the normal change process, with the agent recorded as drafter and a person as the decision's author.
It does not rewrite prose for style, tone or readability, and it does not touch rationale or design intent. Those are not stale in a detectable way, and editing them would replace an author's voice with a machine's under the cover of maintenance.
Facts
| Signals | Referenced object revised · contradicted content · orphaned reference · age versus velocity |
| Strongest | Referenced object revised — mechanical, high confidence |
| Weakest | Age against change velocity — reported as a question |
| Corrections | Draft revisions through the normal change process |
| Attribution | Agent as drafter; a person as the decision's author |
| Low confidence | Finding reported without a draft |
| Urgency | Weighted by outstanding controlled copies and ERP references |
| Never | Publishes · rewrites for style · edits rationale or design intent |
Frequently asked
How does a document go stale without anyone noticing?
Because nothing about the document changes when the thing it describes does. A procedure specifying 4 Nm stays confident and unaltered after the characteristic it referenced moves to 4.5, and the discrepancy is invisible until it shows up as a field return.
Does the agent fix documents itself?
No. It produces a draft revision that enters the normal change process, where a person reviews it and an approver approves it. The agent is recorded as drafter and the person as the author of the decision, and that distinction survives in the audit trail.
What if it cannot produce a confident correction?
It reports the finding without a draft. A finding with no proposal is more useful than a proposal with no confidence, because reviewing a bad suggestion costs more of a reviewer's time than writing the correction themselves would have cost.
Will it rewrite our documents for readability?
No, and deliberately not. Rationale, background and design intent are not stale in a way software can detect, and editing prose for style replaces an author's voice with a machine's under the cover of maintenance. That is not what this is for.
How does it decide what is urgent?
By what the stale document has reached. Eleven outstanding controlled copies at three suppliers is a different problem from an internal draft, and where an ERP read exists, a finding can name the four open purchase orders that reference the affected specification.
What does it need from us to work at all?
Documents with relationships. A document attached to an item revision and referencing typed characteristics is analysable; a PDF sitting in a folder is not. The document-relationship and specifications-as-data work is a genuine prerequisite for this rather than a companion to it.
Is the age signal useful?
Weakly, which is why it is reported as a question rather than a finding. A document untouched for two years describing an assembly that changed nine times is worth a look, but plenty of old documents are old because they are correct and stable.