Neurocroft
    ← Back to selected work
    Neurocroft logo markSelected work · Case study

    AI-governed product knowledge & change-control system

    A human-governed system for maintaining reliable product truth across AI-generated documentation. Every approved claim is traceable, stale downstream pages are detected automatically, and humans approve what becomes truth. Initial story generation, review and cleanup — to a team-discussion-ready draft — fell from several hours to about 15 minutes.
    Applied AIAgentic workflowKnowledge governanceHuman-in-the-loop

    Role

    AI Business Analyst · initiative lead & architect

    Context

    ~15-person AI product team

    Sector

    Agentic AI assistant platform

    Stage

    Active operational system

    55+

    governed components (≈44 docs + aggregators)

    Operational · live system

    ~15 min

    to a team-discussion-ready story draft (from several hours)

    Operational · live use

    24–30

    user stories supported (≈3 sprints)

    Operational estimate

    Daily

    automated stale-content detection

    System behaviour

    01 · Executive summary

    No stable product truth — until documentation was governed like a build system

    An approximately 15-person product team was working from frequently changing, AI-generated product documents. Product thinking was evolving rapidly, but the environment did not distinguish raw ideas, approved decisions, assumptions and derived artefacts — so AI-expanded narrative introduced unapproved detail, technical solutions without a clearly defined human problem, and inconsistent versions of the same intent. The team could not reliably tell what was current, approved or authoritative.

    I redesigned the documentation model around atomic, effective-dated Product Level claims in Confluence, then designed and implemented a DAG-based governance system that records semantic dependencies, detects stale derived content through page versions and folder fingerprints, and coordinates human-approved regeneration in topological order.

    The system now governs more than 55 components — including about 44 Confluence documents, plus aggregators and operational components — runs daily change detection, supports two-week sprint planning and has supported the preparation of roughly 24–30 user stories. Initial story generation, review and cleanup — to a draft ready for team discussion — fell from several hours to about 15 minutes.

    02 · Business problem

    The project had no stable product truth

    The real problem was not documentation volume alone. It was the absence of an authority model and a change-propagation mechanism across an AI-generated knowledge system.

    Constant new AI docs

    Product thinking evolved fast; new AI-generated documents appeared frequently, with no authority model to anchor them.

    AI-expanded narrative

    AI expansion introduced unapproved detail, making product intent hard to separate from generated interpretation.

    Solutions before problems

    Technical solutions appeared before the underlying human problem was clarified.

    Contradictory versions

    Different documents disagreed about the same product intent, with no source of truth.

    Silent changes

    Shifts in product thinking were not always communicated explicitly to the team.

    Stale derived pages

    Architecture, module, function and story pages stayed “current” after their inputs had changed.

    03 · BPMN 2.0 · Business process

    From a raw idea to governed, current product truth

    A single pool with three lanes — the Product Owner, the Governance System & AI agents, and human review. Approved claims, raw ideas and Jira planning live as data objects; a daily, timer-driven cycle identifies stale downstream pages so they can be reviewed before they keep shaping planning and delivery.

    BPMN 2.0 business process: AI-governed product knowledge A single process pool with three lanes — Product Owner, Governance System & AI Agents, and Human Review. A start event (new product idea) leads the Product Owner to capture a raw idea; a separate daily timer start event triggers change detection directly. agents extract atomic claims (reading a raw-ideas data object); a human pre-write review gateway decides whether the claim is approved. Approved claims are recorded to a Confluence data store; a daily change-detection task uses page versions and folder fingerprints; a gateway checks for stale descendants — if none, monitoring continues; if stale, specialist agents triage and regenerate in topological order, reading approved claims and architecture folders. A human final-approval gateway then decides; if approved the process ends with fresh docs published and Jira stories linked, otherwise regeneration repeats. PRODUCT-KNOWLEDGE GOVERNANCE · PROCESS POOL ProductOwner GovernanceSystem & AI HumanReview NoYes YesNo · monitor NoYes New productidea Capture raw idea AIExtract atomicclaims (Rovo) AIRecord approvedclaim Daily changedetectiondaily timer AITriage & regenerate(specialist agents) Claimapproved? Stalepages? Docsapproved? Pre-write review Final approval Fresh docs +linked Jira Raw ideas Approved claims(Confluence) Architecturefolders Legend Start End Task Agent task Data object Data store Sequence flow Data association Gateway (decision)

    Swipe or scroll to explore the diagram →

    Conceptual governance workflow, expressed in BPMN 2.0. Newly created — no client-owned material or internal screens reproduced.

    04 · Solution architecture summary

    Five separated concerns, governed like a build system

    The architecture keeps five concerns apart: ground truth & sources; a governance core; an AI workflow layer; a human-control layer; and delivery outputs. Code identifies possible impact, agents judge likely relevance, and the human decides what becomes truth.

    Claude CoWork hosts the operational dashboard; Claude Code holds the Python scripts, YAML manifest, skills and agents; a local bridge and watcher connect the two environments and restart the bridge when needed.

    Governance core

    1. 01

      YAML DAG manifest of semantic dependencies

    2. 02

      Confluence page-version tracking

    3. 03

      SHA-1 folder fingerprinting

    4. 04

      Stale-state calculation across descendants

    5. 05

      Topological regeneration planning

    05 · Solution architecture

    How the pieces fit together

    Five layers — sources & ground truth, the governance core, the AI workflow, human control, and delivery into Confluence and Jira.

    Solution architecture diagram Five layers left to right: sources and ground truth (approved claims, raw ideas, architecture folders, legal/compliance sources, Jira signals); the governance core (YAML DAG manifest, page-version tracking, SHA-1 folder fingerprinting, stale-state calculation, topological planner); the AI workflow (analyst/orchestrator, change-triage agent, specialist agents for architecture, compliance, module/function and global spec); human control (pre-write review, final approval, mark-fresh, RACI and visibility); and delivery outputs (fresh Confluence docs, linked Jira stories, sprint artifacts). A bottom band shows the operating environment: Claude CoWork dashboard, Claude Code, and a local bridge and watcher. 01 · SOURCES 02 · GOVERNANCE CORE 03 · AI WORKFLOW 04 · HUMAN CONTROL 05 · DELIVERY • Approved Product-Level claims• Untrusted raw ideas• Architecture folders• Legal / compliance sources• Jira planning signals • YAML DAG manifest• Page-version tracking• SHA-1 folder fingerprint• Stale-state calculation• Topological planner Analyst / orchestrator Change-triage agent Specialist agents ArchitecturePolicy / constraintModule / functionGlobal specification • Pre-write review• Final approval• Mark-fresh decisions• RACI• Workflow visibility • Fresh Confluence docs• Linked Jira stories• Sprint planning artifacts OPERATING ENVIRONMENT Claude CoWorkoperational HTML dashboard Claude CodePython scripts · YAML · skills · agents Local bridge & watcherconnects environments · auto-restart

    Swipe or scroll to explore the diagram →

    05 · The knowledge DAG

    Why one edit ripples downstream

    Every derived page records which claims it was built from. When an upstream Product-Level claim changes, the engine walks the dependency graph and flags only its descendants as stale — leaving unrelated branches untouched.

    Knowledge dependency graph A directed acyclic graph from a Product-Level claim through derived pages. When the claim changes, its descendants — architecture, module spec, function spec, user story and Jira story — are flagged stale for regeneration, while the compliance branch that does not depend on it stays fresh. Product-Level claim (changed) ▲ upstream change Architecture page Module spec Function spec User story Jira story Compliance page Reg. mapping Stale — flagged for regeneration Fresh — unaffected branch

    Swipe or scroll to explore the diagram →

    06 · AI components

    What code, AI and humans each decide

    Extraction and regeneration agents work inside explicit boundaries: code finds possible impact, agents judge likely relevance and draft, and a human approves what becomes truth. AI-generated assumptions are labelled for verification.

    AI components — who decides what Three responsibilities kept distinct. AI interprets: extracts proposed atomic claims with Rovo, assesses likely change impact, identifies potentially affected documents, generates proposed updates and labels assumptions for verification. Software governs, deterministically: tracks Confluence page versions, fingerprints folders with SHA-1, calculates stale descendants, orders regeneration topologically and records built-from status. Humans decide: what becomes product truth, which updates are necessary, whether regenerated content is acceptable, when documents are published and marked fresh, and how to resolve ambiguity. AI interprets Software governs Humans decide PROBABILISTIC DETERMINISTIC ACCOUNTABLE Extracts proposed atomic claimsAssesses likely change impactIdentifies affected documentsGenerates proposed updatesLabels assumptions to verify Tracks Confluence page versionsSHA-1 folder fingerprintsCalculates stale descendantsOrders regeneration (topological)Records built-from status What becomes product truthWhich updates are necessaryWhether output is acceptableWhen to publish & mark freshHow to resolve ambiguity Rovo & specialist agents draft — never approve. Code finds impact — it does not judge relevance. The human owns every published truth.

    Swipe or scroll to explore the diagram →

    07 · Technology stack

    The build

    AI environment

    Claude Code

    scripts, YAML, skills, agents

    Claude CoWork

    operational HTML dashboard

    Language & data

    Python

    governance engine & agents

    YAML

    DAG dependency manifest

    SHA-1 fingerprint

    folder change detection

    Atlassian

    Confluence REST

    docs + page versions

    Jira

    linked planning stories

    Atlassian Rovo

    claim-extraction agents

    Automation

    Bridge & watcher

    connects CoWork ↔ Code

    Scheduled runs

    daily change detection

    HTML dashboard

    workflow visibility

    08 · Results

    Operational results from live use

    These figures are self-observed estimates from a live, in-use system rather than a controlled study. The short quality-feedback mechanism is still too new to support a formal performance claim — and reduced rework, fewer defects, faster delivery and full transferability are not yet proven.

    01

    Upstream change

    a claim or source is edited

    02

    Detect stale descendants

    page versions + fingerprints

    03

    Triage & regenerate

    specialist agents, topological order

    04

    Human approve & publish

    fresh docs + linked Jira

    Initial user-story preparationhours → ~15 min
    Before
    several hrs
    Governed
    ~15 min
    24–30user stories supported across ≈3 sprints
    Dailyautomated Confluence change detection

    Self-observed estimate from live use — time to a reviewed, cleaned story ready for discussion with the Product Owner and team.

    55+

    governed documents, aggregators & operational components

    Operational · live system

    4–5

    major upstream change cycles — ~10 downstream docs assessed each

    Operational estimate

    Team impact

    PO & PM approved continued useDevelopers reported clearer objectivesStopped stale planning shaping new storiesSurfaced uncommunicated PO changes

    Stakeholder-reported

    09 · Lessons learned

    What I would carry into the next build

    01

    AI-generated documentation needs an authority model

    The question isn’t whether AI can write a page, but whether everyone can tell what is approved, current, assumed, expired or derived.

    02

    Change propagation matters as much as generation

    Keeping coherence across changing documentation is harder — and more valuable — than generating a page once.

    03

    Documentation can be governed like a build system

    Sources, derived artefacts, versions, stale propagation and topological rebuilding are a strong model for organisational knowledge.

    04

    Human review is strongest before and after execution

    Reviewing the proposed plan prevents bad updates; reviewing the finished page protects the live knowledge base.

    05

    Agent autonomy needs explicit boundaries

    Code identifies possible impact, agents judge likely relevance, and the human decides what becomes truth.

    06

    Transferability must be designed deliberately

    The system leaned on one person’s local setup and product knowledge; packaging and handover are the next priority.

    The Neurocroft method

    The same six moves we apply to any organisational friction

    Notice

    Recognised the team had no reliable “current, approved” product truth.

    Understand

    Modelled the documentation as sources and derived artefacts with dependencies.

    Simplify

    Reduced product intent to atomic, effective-dated claims.

    Connect

    Linked claims, derived docs, agents and Jira in one governed DAG.

    Amplify

    Used agents to detect impact and regenerate, keeping humans deciding.

    Evolve

    Runs daily in live sprint planning; packaging for handover is next.

    Related services

    Where this pattern fits in how we help

    Primary service

    Automation & AI Implementation

    Automation and AI applied only where they create measurable value, with human governance kept intact.

    Read the service

    Also demonstrated

    Data & Decision Intelligence

    Connecting fragmented information sources so the decisions people actually make are backed by trusted, traceable data.

    Read the service
    Neurocroft logo markTalk it through

    Have a process cost you can feel but can't see?

    Start with a short fit call. 20–30 minutes. You describe the situation; we tell you honestly whether AI belongs anywhere near it.

    Get in touch