Docsalient
A repository bot and CI evidence layer separating documentation facts, structural findings, proposed changes, reviewer approval, publication and sampled answer-engine citation observations.
Developer-tool documentation increasingly serves both human readers and automated answer systems. The supplied research confirms a recent product that generates documentation from repositories and reports no citation-structuring or measurement feature in that product. It also reports no reviewed competitor combining pull-request delivery, answerability checks and citation observation. Those are bounded feature findings, not proof that structured documentation will earn citations or customers.
Docsalient would preserve repository and revision, documentation version, page, canonical source, code example source, parser result, factual assertion, question candidate, answerability rule version, structural finding, generated proposal, machine-readable markup proposal, model-facing index proposal, unsupported claim warning, reviewer decision, merged revision, published URL, publication readback, sampled query, locale, answer engine, observation time, returned answer, cited URL, citation position, collection limitation, traffic observation and conversion event as distinct records.
A self-contained page can still be wrong, outdated or unsafe. A valid structured-data block does not guarantee eligibility, indexing or citation. Answer engines vary by time, geography, account and query phrasing, and their interfaces or terms can change. A sampled citation observation does not prove the documentation change caused it; traffic and acquisition outcomes require separate analytics and controlled interpretation. The bot must never invent product behavior from source code, rewrite security guidance without an owner or fail a release solely because an external engine did not cite a page.
The pilot should use a public fixture documentation repository and a fixed set of harmless questions. The likely buyer is a developer-marketing, documentation or growth owner at a software company, but repository scale, release cadence, query demand, review capacity, measurement access, budget and willingness to block merges on structural rules remain unverified.
A developer-marketing, documentation or growth owner responsible for keeping technical pages accurate, answerable and observable across releases.
Documentation, developer-marketing and growth owners are actionable, although scale, review load and budget need validation.
Reusable parsers, rule sets and pull-request delivery can operate across many pages and releases.
The workflow gap is clear, while the input establishes no durable barrier that prevented docs platforms from building it.
The input identifies a clear documentation owner, confirms adjacent generation tooling and describes a specific repository-native measurement workflow.
Most referenced measurement capabilities were not verified, citation sampling is unstable, acquisition causality is weak and established documentation vendors can add structural checks.
Discussion
No comments yet — be the first to weigh in.