slug: information-value
title: "Why Document-as-Code? From Document Production to Information Value"
description: "For leaders and teams: where reuse, review, traceability, and AI can help, and what adoption requires."
slides:
  - id: value
    type: title
    title: We need usable information
    subtitle: Document production is only one part of the work
    context: "Why Document-as-Code? | Benefits and adoption"
    sources: [docs/01-introduction.md, docs/11-beyond-github.md]
    notes: "Begin with a practical question: what information decision is difficult today? This session addresses value and adoption, rather than teaching syntax or configuring tools. The examples are illustrative; they do not establish measured savings."
  - id: duplication
    type: comparison
    title: One change can create several updates
    left:
      title: Independent copies
      items: ["Access instructions in a handbook", "The same text in a training guide", "Another copy on a website"]
    right:
      title: The maintenance problem
      items: ["Find each copy", "Decide which version is accepted", "Check that the wording still agrees"]
    sources: [docs/01-introduction.md]
    notes: "Invite an example of duplicated information from the audience. Independent copies may be appropriate when audiences need different content, but shared facts and instructions need an intentional maintenance strategy. A new repository alone does not resolve that problem."
  - id: reuse
    type: diagram
    title: Reuse the maintained source
    message: Change shared information where it is owned
    steps:
      - { label: Source, detail: "A procedure maintained by its responsible team" }
      - { label: Rules, detail: "Select suitable content and apply presentation choices" }
    outputs: [Handbook, Training, Website]
    caption: "Reuse is designed. Audience-specific wording still needs review."
    sources: [docs/01-introduction.md, docs/10-publishing.md]
    notes: "The intended benefit is fewer independently maintained copies, not identical output everywhere. A training excerpt can omit details that remain in the full procedure. Changes reach an output when its processing and publication rules run."
  - id: accountability
    type: content
    title: Make the history useful to the team
    message: Know who changed what, and which decisions apply
    bullets: ["Find the reason behind an update", "Connect review evidence to a revision", "Investigate a disputed instruction without guessing"]
    sources: [docs/03-project-growth.md]
    notes: "History is useful for explanation and follow-up, not ranking contributors. Commit counts and word counts are activity measures, not quality scores. Identity and review records need to be interpreted within the team's agreed approval process."
  - id: shared-review
    type: comparison
    title: Review the change, not only the document
    left:
      title: A whole publication
      items: ["May be lengthy to reread", "Related copies may be overlooked", "Acceptance can apply to the delivered whole"]
    right:
      title: A focused source change
      items: ["Shows the changed passages", "Includes affected related sources", "Records questions and decisions"]
    sources: [docs/03-project-growth.md, docs/02-github-workspace.md]
    notes: "These are workflow choices, not inherent limitations of word processors. Smaller reviewable changes can improve focus. They do not remove the need to assess a complete publication when its composition, audience, or risk calls for it."
  - id: repeatable-work
    type: content
    title: Automate work that repeats
    message: Let people spend more time on meaning and judgment
    bullets: ["Check required fields and internal links", "Assemble a recurring report", "Publish selected outputs consistently"]
    sources: [docs/07-processing.md, docs/10-publishing.md]
    notes: "Do not promise a percentage improvement without evidence. These are candidates for reducing repeated work. Scripts, checks, and publishing rules require ownership and maintenance; compare that effort with the actual recurring task."
  - id: change-impact
    type: content
    title: Find where a change may matter
    message: Explicit links turn impact assessment into a focused investigation
    bullets: ["A policy changes", "Find procedures that refer to it", "Review the relevant instructions and outputs"]
    sources: [docs/06-information-architecture.md]
    notes: "Use a security policy as the example, not employee task readiness. A reference does not automatically mean a procedure must change. It makes the candidate set visible, so a responsible person can assess the impact."
  - id: ai-value
    type: content
    title: AI becomes more useful with reliable context
    message: Maintained sources give an assistant something concrete to work with
    bullets: ["Prepare an audience-specific excerpt", "Compare related instructions for consistency", "Propose a check or an output template"]
    sources: [docs/08-ai-native.md]
    notes: "The opportunity is more than fluent writing. An agent may inspect a connected set of sources, constraints, and processing code. That also increases the review surface. Protect access boundaries and review generated changes across all affected files."
  - id: costs
    type: comparison
    title: Autonomy brings maintenance responsibility
    left:
      title: Potential value
      items: ["Less repeated assembly", "Visible review and provenance", "Team-controlled improvements"]
    right:
      title: Costs to plan for
      items: ["Learning and contributor support", "Tooling and integration maintenance", "Ownership, access, and review rules"]
    sources: [docs/11-beyond-github.md, docs/02-github-workspace.md]
    notes: "Not every conversation or temporary note needs this treatment. A hybrid approach can keep authoritative information in existing systems and import only what is needed. Teams need practical permission to improve their workflow, with boundaries for security and platform responsibilities."
  - id: pilot
    type: content
    title: Pilot a real information problem
    message: Measure the outcome before extending the platform
    bullets: ["Pick one recurring source-to-output task", "Agree an owner, consumer, and review rule", "Compare update effort, defects, and usefulness after use"]
    sources: [docs/11-beyond-github.md, docs/03-project-growth.md]
    notes: "Choose measures suited to the problem rather than tracking more activity for its own sake. Review results with the people maintaining and consuming the information. Continue only where the benefit justifies the effort. The tutorial's labs provide examples, not a universal adoption score."