Enterprise communication field guide · 2026-07-19

Say the right thing, in the right form, to the right reader.

Plan decisions, shape evidence, choose the right artifact, and produce communication that people can understand, trust, and act on.

Start with the reader Choose a form Use a playbook

12 principles
18 playbooks
92 sources
searchable · offline
light · dark · auto

Part I · Chapter 01

Use the guide

Begin with the work the reader must accomplish. Then choose the form, evidence, and level of detail that make that work easier.

Define the outcome

State who the reader is, what they need to understand or decide, and what should happen next.

Route by reader intent →

Choose the form

Select the genre and argument structure that match the task. Do not force every problem into a document, deck, or dashboard.

Compare forms and structures →

Build in layers

Lead with orientation and the main conclusion. Follow with reasoning, evidence, implementation detail, and source material.

Open the playbooks →

Use the chapter navigation to browse. Use search to retrieve a form, practice, failure mode, or source directly. Source chips connect guidance to the reference library without interrupting the reading flow.

Part I · Chapter 02

Twelve principles

The commitments underneath every playbook that follows. Each carries its sources.

Intent before format. Choose the reader task and decision before choosing a document, page, diagram, or deck.

Evidence before authority. Make source quality, applicability, uncertainty, and reasoning inspectable. Expertise is demonstrated through traceability.

Preserve depth, publish layers. Keep full evidence and provenance in the canonical layer. Publish progressively reduced views for each audience and channel.

Build knowledge once; render many ways. Separate claims, concepts, evidence, decisions, examples, and procedures from individual output layouts.

Structure is meaning. Semantic headings, relationships, labels, and content boundaries serve humans, assistive technology, search, and retrieval systems.

Explain why before how. Connect purpose, problem, evidence, causality, priority, choice, and accepted trade-offs before implementation detail.

Trade-offs over advocacy. Show what improves, what worsens, who benefits, who pays, and what future options are preserved or constrained.

Personas are bounded models. Use personas only for declared decisions and contexts. Prefer behavioral evidence over invented biography.

Make reasoning inspectable. Store claims, grounds, warrants, qualifiers, assumptions, rebuttals, alternatives, and decision criteria.

Define measurable audience impact. State what the audience should know, decide, do, verify, or explain after using an artifact.

Accessibility and ethics are architectural. Do not reserve semantic structure, inclusive participation, privacy, or persuasion integrity for final review.

Version knowledge; do not overwrite it. Supersede claims and recommendations with an epistemic change log. Preserve rejected challenges and prior states.

Part I · Chapter 03

Start with the reader

Format is the last choice, not the first. Begin from what the reader is trying to do, and let that select the form.

Orient, teach, help act, support decisions, enable verification, operate, persuade, and retrieve.

Communication quality depends on alignment, not prose polish alone.

A strong artifact aligns reader intent, evidence strength, decision purpose, information architecture, and delivery medium.

In practice — Declare purpose, audience, decision, and intended action before drafting.

A universal document creates conflicting contracts.

Tutorials, references, decision memos, specifications, and marketing pages optimize for different questions.

In practice — Use shared canonical knowledge with separate task-specific views.

Comprehensive and usable can coexist through layering.

Depth belongs in the source layer; progressive disclosure determines what each reader sees first.

In practice — Preserve full research and publish bounded views.

Every substantive unit should have a declared job.

Paragraphs and sections should advance a claim, explain a concept, provide evidence, support action, or preserve context.

In practice — Remove or relocate units that serve no declared purpose.

Part II · Chapter 04

Choose the form

The atlas: what each genre is for, its skeleton, and what it should never be asked to do — then the argument structures that organize them.

Genres

Research note

Capture one observation, source, or question.

Question → observation → source → interpretation → follow-up

Not for — Not a final conclusion.

Annotated bibliography

Record what a source contributes and how reliable it is.

Citation → summary → quality → useful claims → limitations

Not for — Do not treat separate annotations as synthesis.

Literature review

Map existing knowledge, debates, methods, and gaps.

Scope → method → themes → agreement → conflict → gaps → implications

Not for — Do not organize only by source.

Research paper

Contribute an original argument, method, or result.

Introduction → method → results → discussion → limitations

Not for — Not an operational procedure.

Experiment or benchmark report

Make a test reproducible and its result bounded.

Hypothesis → environment → method → metrics → results → interpretation

Not for — Do not generalize beyond workload and environment.

Case study

Explain an intervention and outcome in context.

Context → problem → intervention → outcome → limits → transferable lesson

Not for — One case is not universal proof.

White paper

Educate and establish a defensible direction.

Problem → evidence → approach → value → implementation → next action

Not for — Do not present advocacy as independent academic evidence.

Executive brief

Enable a rapid consequential decision.

Decision → significance → evidence → options → recommendation → risk

Not for — Do not make the decision request implicit.

Narrative memo

Develop shared context and reasoning.

Situation → tension → evidence → alternatives → recommendation → consequences

Not for — Not ideal for primarily visual demonstrations.

Business case

Justify investment or prioritization.

Problem → strategic fit → options → net value → risk → recommendation

Not for — Do not count transferred costs as savings.

Proposal

Request permission, funding, or commitment.

Need → response → scope → deliverables → resources → risk → acceptance

Not for — Not a status report.

RFC

Collect broad review before a meaningful change.

Summary → motivation → design → alternatives → compatibility → rollout → open questions

Not for — Avoid for trivial local choices.

ADR

Preserve one significant architecture decision.

Context → decision → status → consequences → revisit conditions

Not for — Not a substitute for the complete system design.

PRD

Align on user and product outcomes.

Problem → goals → requirements → non-goals → measures → constraints

Not for — Do not bury technical implementation decisions inside product language.

Functional specification

Describe expected behavior.

Actors → scenarios → behavior → rules → errors → acceptance

Not for — Does not replace an implementation design.

Technical specification

Provide an implementation and operational blueprint.

Context → requirements → architecture → interfaces → security → operations → rollout

Not for — Premature when the solution remains exploratory.

Tutorial

Help a learner acquire competence.

Outcome → prerequisites → guided sequence → checkpoints → result → next step

Not for — Do not double as exhaustive reference.

How-to guide

Help a competent reader accomplish a task.

Goal → prerequisites → steps → expected result → recovery

Not for — Do not teach the whole conceptual domain.

Reference

Support exact lookup.

Definition → syntax → parameters → constraints → examples → errors

Not for — Do not force a learning journey.

Explanation

Build a mental model.

Definition → relationships → mechanism → examples → boundaries

Not for — Do not disguise procedures as theory.

Runbook

Support reliable operation and recovery.

Trigger → diagnosis → action → validation → escalation → rollback

Not for — Do not bury it in architecture prose.

Postmortem

Learn from an incident and improve controls.

Impact → timeline → causes → contributing conditions → actions → verification

Not for — Avoid blame and retrospective certainty.

Thought-leadership article

Establish a defensible point of view.

Thesis → context → evidence → synthesis → implications

Not for — Do not use novelty of tone as evidence.

Landing page

Move a qualified reader toward a bounded action.

Identity → relevance → outcome → mechanism → proof → constraints → action

Not for — Do not ask for conversion before understanding.

Deliver recurring signal and utility.

Issue thesis → findings → interpretation → links → action

Not for — Do not reproduce the entire research report.

Presentation

Guide a time-bound spoken argument.

Assertion → evidence → transition → decision

Not for — A deck is not the durable source of truth.

Policy

State mandatory organizational requirements and rationale.

Purpose → scope → requirements → responsibilities → exceptions → enforcement

Not for — Do not use should when must is intended.

Guideline

Provide context-sensitive recommended practice.

Context → recommendation → rationale → exceptions → examples

Not for — Do not make optional guidance appear mandatory.

Structures

IMRaD

Experimental or systematic research

Introduction → Methods → Results → Discussion

Separates what was done, observed, and inferred.

CARS

Research and proposal introductions

Establish territory → establish niche → occupy niche

Explains why the contribution is necessary.

Claim–evidence–analysis

Research paragraphs and enterprise recommendations

Assertion → evidence → interpretation → implication → action

Prevents citation dumping without reasoning.

Toulmin

Conditional practical recommendations

Claim → grounds → warrant → backing → qualifier → rebuttal

Exposes hidden reasoning and exceptions.

Classical argument

Strategic advocacy and major presentations

Relevance → context → position → proof → refutation → action

Creates a broad persuasive arc.

Rogerian argument

Legitimate stakeholder conflict

Neutral issue → opposing view → valid conditions → own view → shared goals → resolution

Finds common ground without erasing trade-offs.

Policy memo

Executive decision

Decision → evidence → options → comparison → recommendation → implementation

Optimizes for a specific decision-maker.

Technical story

Engineering articles and transformation narratives

Context → friction → failed obvious answer → insight → decision → implementation → outcome → limits

Uses change to explain causality and learning.

Data story

Analytical communication

Question → baseline → contrast → explanation → consequence → action

Moves from measurement to decision.

Assertion–evidence

Presentations

Complete-sentence assertion + supporting visual evidence

Reduces topic headings and bullet walls.

Enterprise why chain

Recommendations

Purpose → problem → evidence → causality → priority → choice → trade-off → how

Explains why before implementation.

Part II · Chapter 05

Playbooks

Step sequences for the outputs you actually ship. Each starts from purpose, never from format.

Playbook

Reader-intent router

Select the correct communication form before authoring.

Orient — Landscape, glossary, system context, executive summary
Learn — Tutorial with guided sequence and checkpoints
Act — How-to, procedure, checklist, or runbook
Decide — Memo, business case, RFC, or options analysis
Verify — Reference, specification, standard, or source registry
Understand — Explanation, architecture narrative, or literature synthesis
Persuade — Argument, proposal, landing page, or presentation
Retrieve — Atomic answer unit with evidence and local context

Playbook

Literature review

Synthesize a field without becoming a list of sources.

1 — Define scope, questions, terminology, and selection method
2 — Map theories, methods, populations, and source quality
3 — Organize themes, convergence, disagreement, and gaps
4 — Separate evidence from enterprise transfer inference
5 — Conclude with implications, limitations, and research agenda

Playbook

IMRaD research report

Preserve methodological inspectability.

Introduction — Problem, prior knowledge, gap, and research question
Methods — Population, environment, instruments, variables, and analysis
Results — Observations without advocacy
Discussion — Interpretation, limitations, transferability, and recommendation

Playbook

Enterprise technical specification

Connect design to implementation, operations, and outcomes.

Control — ID, owner, status, reviewers, version, classification
Context — Current state, trigger, goals, non-goals, constraints
Design — Architecture, components, data, interfaces, identity
Quality — Security, privacy, accessibility, performance, resilience
Lifecycle — Testing, migration, rollout, rollback, operations, ownership
Decision — Alternatives, trade-offs, open questions, measures, references

Playbook

Architecture view contract

Make every diagram answer a declared concern.

Audience — Who reads this view?
Concern — What question does it answer?
Scope — What is included, excluded, and abstracted?
Notation — Legend, boundaries, direction, and time perspective
Narrative — Reading order, primary flow, decisions, failures, operations
Lineage — Source definitions, ADRs, owner, and last verified

Playbook

Persona Stack

Prevent a static profile from substituting for context.

Population — Who may be affected?
Segment — Which measurable pattern matters?
Persona — What recurring behavioral decision pattern exists?
Situation — What is happening now?
Baseline — What is known, believed, and currently done?
Impact — What should change after communication?
Constraints — Time, device, environment, authority, accessibility

Playbook

Persona foundation package

Turn a persona into governed research infrastructure.

Operational card — Concise daily reference
Foundation document — Full research basis, scope, synthesis, and limitations
Evidence matrix — Attribute-level observed, measured, inferred, and hypothesized evidence
Scenario library — Tasks and situations where the model applies
Impact contracts — Desired knowledge, decision, behavior, and guardrails
Lifecycle — Version, validation, drift signals, and retirement

Playbook

Persona Impact Contract

Define a measurable communication outcome.

Baseline — Knowledge, attitude, behavior, authority, and barriers
Desired cognition — Know, distinguish, remember, and explain
Desired decision — Compare, approve, reject, prioritize, or escalate
Desired behavior — Start, stop, complete, adopt, configure, or share
Evidence threshold — Proof required for trust and action
Guardrail — Dangerous interpretation or action to prevent
Measurement — Indicator, threshold, time horizon, and dependencies

Playbook

Toulmin argument

Make a recommendation inspectable.

Claim — What exactly is recommended?
Grounds — What evidence supports it?
Warrant — Why does the evidence imply the claim?
Backing — Why should the warrant be accepted?
Qualifier — Where and with what confidence does it apply?
Rebuttal — When is the claim invalid or incomplete?

Playbook

Enterprise why chain

Explain why before how.

Purpose — What human or organizational objective matters?
Problem — What is insufficient today?
Evidence — How do we know?
Causality — Why should the intervention work?
Priority — Why now?
Choice — Why this option?
Trade-off — Why are disadvantages acceptable?
How — Architecture, ownership, controls, migration, and operation

Playbook

Decision paper

Enable a defensible enterprise choice.

Decision — Decision requested and recommendation
Stakes — Why now and consequence of inaction
Evidence — Current-state findings and root causes
Options — Status quo, alternatives, and evaluation criteria
Value — Outcomes, beneficiary, mechanism, baseline, and uncertainty
Trade-offs — Short, medium, long, exit, reversibility, and lock-in
Execution — Ownership, milestones, controls, validation, and stop conditions

Playbook

Time-expanded trade-off analysis

Prevent short-term value from hiding future cost.

Immediate — Delivery, disruption, migration, and approval
Near term — Adoption, training, stability, and initial value
Medium term — Operating cost, scaling, debt, and dependencies
Long term — Strategic flexibility, lock-in, and architecture evolution
Exit — Replacement, decommissioning, portability, and residual obligations

Playbook

Assertion–evidence presentation

Build a deck around claims rather than topics.

Assertion — One complete sentence that advances the argument
Evidence — A diagram, chart, image, or bounded data display
Narration — What cannot be inferred from the visual alone
Source — Visible or note-level citation
Transition — Why the next assertion follows
Companion — Durable document with methods, caveats, and detail

Playbook

Research workflow

Move from question to governed publication.

Frame — Objective, decision, audience, scope, terms, evidence bar
Collect — Standards, reviews, primary studies, first-party cases, commentary
Assess — Authority, method, relevance, independence, applicability
Extract — Claim, evidence, method, limits, contradiction, locator
Synthesize — Convergence, disagreement, context, gaps, implications
Validate — Fact, citation, technical, adversarial, accessibility, retrieval
Publish — Output manifest and channel-specific assembly
Maintain — Owner, verification interval, supersession, and archive

Playbook

Future Research Continuity Package

Enable reproduction, audit, independent review, and extension.

Sources — Immutable evidence, snapshots, hashes, licenses, locators
Registry — Source quality, methods, scope, conflicts, claims supported
Knowledge — Atomic claims, evidence, concepts, assumptions, limitations
Arguments — Warrants, qualifiers, rebuttals, alternatives, decisions
Audiences — Personas, situations, impact contracts, affected parties
Provenance — Agents, activities, derivations, prompts, reviews
Challenges — Open, resolved, and rejected adversarial findings
Evaluations — Citation, calibration, trade-off, persona, temporal tests
Package — README, schemas, RO-Crate metadata, manifest, changelog

Playbook

Future-agent independent review protocol

Challenge without silently rewriting history.

Integrity — Verify sources, versions, hashes, quotations, and dates
Evidence — Check claim scope, source support, causality, and applicability
Argument — Challenge warrants, assumptions, qualifiers, and rebuttals
Alternatives — Add status quo, hybrid, and omitted options
Trade-offs — Expose transferred cost, time horizon, reversibility, and lock-in
Audience — Identify missing personas, affected parties, and accessibility
Freshness — Check superseded standards, new research, and changed practice
Expansion — Append sources, claims, challenges, and a versioned synthesis

Playbook

Content compiler

Render one knowledge base into many channels.

Canonical objects — Claims, concepts, evidence, decisions, procedures, examples
Audience contract — Persona, situation, baseline, authority, and desired impact
Output manifest — Genre, hierarchy, included objects, evidence rules, CTA
Renderer — Article, SPA, deck, memo, docs, newsletter, or retrieval chunk
Validator — Facts, citations, terminology, accessibility, and policy
Feedback — Observed outcome updates content and audience models

Part III · Chapter 06

Evidence & argument

How claims earn belief: source hierarchies, argument skeletons, and the discipline of showing your uncertainty.

Academic and research structures

Research introductions require a gap and contribution.

Background alone does not establish why new work is needed.

In practice — Use territory, niche, and contribution moves.

Methods and results should remain distinct from interpretation.

Readers need to inspect how evidence was produced before accepting conclusions.

In practice — Use IMRaD for experiments, benchmarks, surveys, and formal evaluations.

Literature reviews synthesize themes rather than narrate a reading list.

Source-by-source summaries transfer analytical work to the reader.

In practice — Organize agreement, disagreement, methods, limitations, gaps, and implications.

Evidence and argumentation

Evidence must match the claim.

Standards, experiments, company practices, and professional heuristics support different kinds of conclusions.

In practice — Label evidence class, scope, confidence, and limitations.

A citation does not automatically support the sentence attached to it.

The source may provide context, a method, partial support, or direct contradiction.

In practice — Record citation intent and exact source locators.

The warrant is the most frequently hidden part of an enterprise argument.

Evidence does not determine a recommendation without a rule connecting observation to action.

In practice — Store warrants, backing, qualifiers, and rebuttals as first-class objects.

Part III · Chapter 07

Technical & architecture writing

Documentation and architecture records that stay true as systems change.

Technical documentation and specifications

Treat documentation as a product and platform capability.

It has users, journeys, quality attributes, analytics, defects, ownership, release cycles, and deprecation.

In practice — Assign product ownership, measurement, and lifecycle controls.

Platform documentation is more useful when attached to supported journeys.

In platform-engineering contexts, tool inventories alone may not help people complete supported work; documentation, tooling, and paved paths work better as one enablement system.

In practice — Organize platform content around Golden Paths, paved roads, and bounded tasks.

An enterprise technical specification extends beyond code structure.

Security, privacy, data, performance, failure, observability, rollout, rollback, support, and measures define enterprise readiness.

In practice — Adopt a complete specification standard with explicit non-goals and alternatives.

ADRs preserve durable decision rationale.

A system design changes; the reasons behind significant choices remain important for future maintainers.

In practice — Record context, options, decision, consequences, risks, and revisit conditions.

Architecture communication

A diagram is a stakeholder view, not the architecture.

Different concerns require different abstractions, notation, and scope.

In practice — Declare audience, concern, scope, omissions, legend, and last verification.

Architecture diagrams usually require prose.

Lines and boxes do not reliably communicate ownership, trust, failure, causality, or rationale.

In practice — Explain purpose, reading order, flows, boundaries, decisions, failures, and operational implications.

Context and container views often cover many stakeholder needs.

Excessive component or code detail can obscure enterprise boundaries and responsibilities.

In practice — Start at the highest useful abstraction and add detail only for an explicit question.

Part III · Chapter 08

Story & marketing

Narrative that carries meaning without inflating it — inside the company and out.

Storytelling and presentations

Useful stories connect change and consequence, not chronology alone.

A practical narrative can connect an initial state, goal, tension, choice, changed state, and implication; the exact sequence is a synthesis pattern rather than a universally validated formula.

In practice — Use narrative to guide attention, then reconnect the case to aggregate evidence.

A vivid incident does not establish prevalence.

Narratives can be memorable enough to overpower base rates and broader data.

In practice — Label examples as illustrative and pair them with measured frequency or scope.

Slides are guided experiences; they are weak repositories.

Dense slides compete with narration and are difficult to reuse independently.

In practice — Use assertion–evidence slides with notes, appendices, and a companion source document.

Marketing, newsletters, and conversion

Marketing claims must not outrun evidence.

Demonstrated outcomes, customer reports, projections, capabilities, and aspirations have different epistemic status.

In practice — Classify every external claim before publication.

The CTA is a decision interface.

Generic labels can move readers into flows before they understand the consequence.

In practice — Use action-specific labels appropriate to audience authority and readiness.

A newsletter needs a recurring job.

A list of new content does not create sustained utility.

In practice — Lead with a signal, explain significance, provide evidence, and use one primary action.

Premium content should add differentiated operational utility.

The cited freemium evidence supports context-specific relationships among perceived value, satisfaction, and conversion. Broader claims that gating basic understanding weakens trust remain a hypothesis.

In practice — Monetize depth, proprietary data, tools, benchmarks, support, and customization.

Part III · Chapter 09

Personas & audiences

Modeling readers without stereotyping them.

Populations, segments, archetypes, situations, impact contracts, validation, ethics, and lifecycle.

A persona is a bounded behavioral decision model.

It is not an average user, demographic stereotype, role, or real participant.

In practice — State population, decision domain, situation, confidence, and prohibited uses.

Persona specificity can reduce representativeness.

Combining many details can create an improbable composite that matches few real people.

In practice — Include only attributes that materially change a decision or communication need.

The least fictional persona is usually safer.

Names, photographs, and lifestyle details may improve memory while increasing projection and stereotyping.

In practice — Prefer archetypes and behavioral labels for enterprise work.

Persona, situation, and job are separate.

The same senior engineer has different needs while learning, troubleshooting, approving, or presenting.

In practice — Use a Persona Stack: population → segment → persona → situation → baseline → impact.

Enterprise artifacts often require an audience constellation.

Implementers, approvers, operators, reviewers, affected parties, and future maintainers often have conflicting concerns.

In practice — Define one primary reading path and layered secondary views.

Audience Impact Contracts are a proposed way to make audience goals measurable.

Replacing “inform the audience” with observable knowledge, decision, behavior, evidence, and guardrail outcomes creates a testable communication contract.

In practice — Specify baseline, desired knowledge, decision, behavior, evidence threshold, guardrails, and measure.

Persona attributes require provenance.

Observed, reported, measured, inferred, hypothesized, and illustrative data have different validity.

In practice — Maintain an attribute-level evidence matrix.

Persona-based recruitment can become circular validation.

Recruiting only people who fit an existing profile cannot reveal missing segments or invalid assumptions.

In practice — Include contrast cases, holdout samples, disconfirming evidence, and participants who fit none.

Synthetic personas are not user evidence.

Models can generate plausible language without reproducing population behavior or prevalence.

In practice — Label synthetic output as hypothesis and validate with real participants and operational data.

Participant evidence and persona synthesis must remain separate.

Saying “the persona needs this” can erase the actual sample and variation.

In practice — Report participant findings first, then link the bounded synthesis.

Part III · Chapter 10

Persuasion with integrity

Moving a decision while leaving the reader's judgment intact.

Logos, ethos, pathos, elaboration, reactance, inoculation, framing, uncertainty, and argument structures.

Responsible persuasion should improve informed choice.

The purpose is not agreement at any cost; it is a defensible decision made with material evidence and consequences visible.

In practice — Evaluate persuasive effectiveness and epistemic integrity separately.

Logos, ethos, and pathos serve different functions.

Reasoning establishes defensibility, credibility establishes trust, and consequence establishes significance.

In practice — Let emotional force remain proportional to evidence strength.

Enterprise communication can benefit from a dual-layer argument.

Decision-makers may scan rapidly while consequential decisions still require substantive scrutiny; a concise decision layer plus inspectable evidence is a defensible design inference.

In practice — Lead with decision, stakes, strongest evidence, and trade-off; preserve full methods and analysis.

Credibility is claim- and context-specific.

Expertise about one product or method does not guarantee independence or applicability elsewhere.

In practice — Assess competence, integrity, independence, accountability, verifiability, relevance, and currency.

Controlling language can trigger resistance.

Mandates, artificial inevitability, and suppression of alternatives threaten perceived autonomy.

In practice — Separate mandatory constraints from recommendations, preserve exceptions, and explain reversibility.

Credible objections should be addressed before approval.

Inoculation and prebunking expose the audience to objections and reasoned responses.

In practice — Steelman predictable counterarguments and define conditions where they are valid.

Framing can change the perceived attractiveness of the same option.

Gain, loss, cost, status-quo, and downside frames activate different reference points.

In practice — Evaluate every material option through multiple equivalent frames.

Explicit uncertainty can support calibrated trust.

Vague uncertainty is less useful than a range, cause, sensitivity, and operational consequence.

In practice — Separate measurement, forecast, implementation, market, and behavioral uncertainty.

Toulmin is a useful default for conditional enterprise recommendations.

Claims are conditional; warrants, qualifiers, and rebuttals determine whether a recommendation actually follows.

In practice — Expose the complete argument map.

Rogerian structure is useful for legitimate organizational tension.

Security versus speed and standardization versus autonomy can both contain valid interests.

In practice — Identify shared goals and create bounded defaults with explicit escape conditions.

Part III · Chapter 11

Value & trade-offs

A recommendation earns trust by naming what it costs, in the dimensions the business actually counts.

Net value, beneficiary and cost bearer, reversibility, option value, debt, lock-in, and time horizons.

Business value should be modeled as multidimensional.

Revenue and labor savings often omit customer, operational, strategic, technical, workforce, risk, governance, and learning outcomes. This taxonomy is a synthesis framework, not established by the policy-memo source alone.

In practice — Use a complete value model and name the beneficiary.

Value requires a causal chain.

A capability is not automatically an outcome. Every link from technical change to business consequence needs evidence or a labeled hypothesis.

In practice — Store outcome → beneficiary → mechanism → measure → baseline → horizon → uncertainty.

Net value includes transferred and recurring costs.

A proposal may save application-team time while increasing platform, operations, security, procurement, or future-maintainer burden.

In practice — Name both beneficiary and cost bearer.

Short- and long-term effects should not share one pros-and-cons list.

Transition disruption, near-term adoption, medium-term operating cost, long-term lock-in, and exit obligations are different analyses.

In practice — Evaluate immediate, near, medium, long, and exit horizons.

Reversibility is both technical and organizational.

A decision can be technically reversible yet economically, contractually, operationally, or politically locked in.

In practice — Estimate exit time, retained obligations, lost data, retraining, and dependency unwinding.

Option value can exceed immediate ROI in uncertain environments.

Pilots, interfaces, dual-run capability, export paths, and stop/go milestones preserve future choices.

In practice — Ask what later decisions become easier or harder.

Technical debt is a time-shifted decision.

The metaphor is useful only when the shortcut, benefit, principal, interest, owner, and repayment trigger are explicit.

In practice — Do not use technical debt as a generic label for disliked code.

Lock-in is multidimensional.

Data export alone does not address API, identity, telemetry, skill, contract, process, and organizational lock-in.

In practice — Assess switching cost across every dependency dimension.

Exploration and exploitation require different measures.

Speculative learning cannot be governed only by the utilization and predictability metrics of mature operations.

In practice — Classify investments as core scale, experiment, option creation, maintenance, or debt repayment.

Part III · Chapter 12

Writing for retrieval

Readers now include machines. Structure, metadata, and chunking decide whether your work is found and quoted faithfully.

Semantic chunks, local context, reranking, validation, authoritative sources, and model-independent adapters.

Human-readable structure often improves machine retrieval.

Descriptive headings, bounded topics, explicit entities, local context, citations, dates, and versions support both people and retrieval.

In practice — Design semantic content units before embedding or indexing them.

AEO is authoritative retrievability, not magic markup.

Current search guidance does not require special AI-only schemas in place of people-first content and established indexing foundations.

In practice — Make claims distinctive, indexable, verifiable, internally linked, and textually available.

Chunk at semantic boundaries.

Fixed character windows can split claims from context, evidence, limitations, or procedures.

In practice — Use concepts, claims, decisions, procedures, failure modes, and examples as retrieval units.

Retrieved units require local context.

Pronouns and references such as “this approach” lose meaning when isolated.

In practice — Use explicit nouns, defined terms, source IDs, scope, and limitations inside each unit.

In the cited production systems, bounded context mattered more than simply increasing context.

The Airbnb examples support targeted retrieval, relevant context, and validation in specific production systems; they do not establish a universal context-window law.

In practice — Retrieve bounded evidence, rerank it, and validate generated output against authority.

LLM transformation requires validation.

Models can classify, summarize, restructure, and generate alternate views while introducing unsupported facts or losing boundaries.

In practice — Validate citations, technical facts, dates, policies, and schemas before publication.

The okf-skills implementation uses deep links and backlinks to navigate beyond the folder tree.

The implementation visualizes typed metadata, outgoing links, citations, and backlinks and gives every concept a shareable fragment deep link.

In practice — Generate stable concept anchors and backlink indexes in the SPA and graph view; compile typed research relationships into JSON-LD.

Public structured data and internal research graphs are best treated as separate projections.

Schema.org can accurately describe the visible public artifact, while an internal graph can express richer provenance, citation intent, claims, challenges, and agent activities. This separation is an architecture recommendation, not a Schema.org requirement.

In practice — Generate a constrained public JSON-LD block and a downloadable enterprise research graph from the same canonical OKF bundle.

Part IV · Chapter 13

Failure modes

The named ways good intentions go wrong. Recognize the shape early.

Failure mode

Universal-document failure

Everything in one artifact. Onboarding, explanation, API lookup, governance, marketing, and operations compete for hierarchy.
One audience label. A role such as “engineer” hides task, expertise, situation, authority, and consequence of error.
Comprehensiveness as visible density. Preserving source depth is confused with placing all detail in the first view.

Failure mode

Evidence theater

Citation dumping. Sources appear without synthesis, exact support, or citation intent.
Authority substitution. A famous company or expert replaces applicability analysis.
Precision theater. Exact forecasts imply confidence that input quality does not support.
Confidence laundering. A hypothesis or company practice is rewritten as established fact.

Failure mode

Persona fiction

Decorative biography. Age, photograph, hobbies, and family details do not affect the decision.
Circular validation. The persona defines recruitment and the matching sample is used to validate the persona.
Synthetic user evidence. Model-generated responses are reported as participant findings.
Permanent snapshot. A persona remains active without evidence-triggered review.

Failure mode

Persuasion without integrity

False urgency. A deadline lacks external constraint or cost-of-delay analysis.
Artificial inevitability. Trends or executive preference are presented as proof of local fit.
Suppressed objections. Real alternatives or credible counterarguments are removed.
Emotional asymmetry. Inaction risks are vivid while action risks remain abstract.
CTA beyond authority. The reader is asked to approve or implement something they cannot control.

Failure mode

Trade-off compression

Single pros-and-cons list. Transition, operating, strategic, and exit consequences are mixed together.
Status-quo omission. The recommendation is compared only with weak alternatives.
Transferred cost as savings. One team’s reduced work becomes another team’s uncounted burden.
Technical reversibility claim. Contract, data, process, skill, and political lock-in are ignored.
Sunk-cost argument. Past investment is treated as a reason to continue regardless of future value.

Failure mode

Architecture ambiguity

Everything diagram. Multiple abstraction levels and concerns appear in one unreadable view.
Diagram without narrative. Ownership, trust, failure, and rationale are left to visual inference.
Color-only semantics. Meaning disappears for some readers, print, or alternative rendering.
Unversioned view. The diagram’s source, owner, and current validity are unknown.

Failure mode

Slide–document hybrid

Paragraph slides. The audience reads while the speaker narrates competing information.
Topic-title deck. Slides label categories but make no assertions.
Deck as source of truth. Methods, caveats, and citations disappear when the speaker is absent.

Failure mode

Marketing overreach

Capability becomes outcome. The causal chain to business value is not shown.
Seamless and zero-risk. Unmeasurable absolutes replace conditions and constraints.
Understanding is gated. The reader must register or pay before understanding the offer.
Generic CTA. Learn more or get started obscures what happens next.

Failure mode

LLM knowledge debt

Final prose only. Future models cannot audit sources, warrants, challenges, or missing evidence.
Embeddings as canonical data. An index replaces human-readable and structured source material.
Unlimited context. Large noisy input replaces targeted retrieval and validation.
Silent model transformation. Prompt, model, retrieval set, and reviewer are not recorded.

Failure mode

Silent history loss

Overwrite instead of supersede. Prior claims and their context disappear.
Rejected challenge deletion. Future reviewers cannot see what was considered and why it was rejected.
Text-only changelog. The wording changed, but the knowledge change is not explained.
Unowned living document. No person or team is responsible for verification and retirement.

Part IV · Chapter 14

Stewardship & governance

Knowledge that outlives its author: versioning, provenance, and review that prove themselves.

Research continuity and future agents

Future agents need research objects, not only final prose.

A final article hides the source graph, reasoning, unresolved questions, and rejected alternatives.

In practice — Store sources, claims, evidence, warrants, assumptions, recommendations, challenges, and outputs independently.

A URL is not durable evidence.

Resources change, disappear, or are silently revised.

In practice — Store canonical and archived URIs, retrieval date, publication date, version, hash, license, and exact locator.

Citation intent should be machine-readable.

Future reviewers need to distinguish support, dispute, method reuse, extension, and background.

In practice — Type each citation relationship.

Exact source annotations reduce reinterpretation risk.

Document-level references force later agents to rediscover the passage and may invite unsupported paraphrase.

In practice — Store quotation selectors, prefixes, suffixes, page or section, and associated claim.

Provenance must include LLM activity.

Future researchers need to know which model, prompt, retrieval set, tools, and human review generated a transformation.

In practice — Represent sources, activities, agents, derivations, approvals, and rejections.

Research packages should use open, model-independent formats.

A future model should not require the current vendor, context-window design, or proprietary application.

In practice — Use Markdown, JSON/YAML with schemas, JSON-LD, CSV/Parquet, text diagrams, IDs, hashes, and tests.

Structured challenge records are first-class knowledge objects.

Silently editing a conclusion destroys the history of why the recommendation changed.

In practice — Append challenges, resolution status, evidence, and epistemic change logs.

Future-agent evaluation should test more than output fluency.

Citation fidelity, claim calibration, argument completion, trade-off completeness, persona consistency, and temporal updating form a proposed evaluation suite.

In practice — Store test cases with expected criteria, not one frozen answer.

Enterprise governance and measurement

Every substantive object needs an owner and lifecycle.

Correct information becomes unsafe when its verification date, scope, or replacement relationship is unknown.

In practice — Store status, owner, version, review triggers, supersession, and retirement.

Normative keywords need a declared convention.

When MUST, SHOULD, MAY, and related terms carry defined requirement levels, the document should state the governing convention and apply it consistently.

In practice — Define normative terms and separate policy, standard, procedure, and guideline.

Communication success should include task success, not engagement alone.

Clicks and time can signal interest, confusion, or friction. Pair engagement measures with observable knowledge, decision, completion, error, or recovery outcomes.

In practice — Measure comprehension, decision accuracy, task completion, error, retrieval, confidence calibration, and accessibility.

A recommendation requires revisit conditions.

Enterprise decisions are made under bounded evidence and changing environments.

In practice — Define assumptions, success thresholds, stop conditions, rollback, and review triggers.

The current soft-mode template is safer than silent autonomous rewriting.

The agent template reads relevant knowledge before work, updates affected concepts afterward, appends logs, and runs validation, while deliberately avoiding hidden hooks.

In practice — Require proposed diffs, contribution records, human review for material changes, and an epistemic log that preserves superseded states.

Source authorship and synthesis contribution are separate provenance dimensions.

The creator of an underlying paper, specification, repository, or video remains the source creator when a human researcher and AI system transform it into a new synthesis. The owner-supplied video is illustrative, not independent corroboration.

In practice — Record source creator and publisher, human research owner, software-agent contribution, derivation activity, review status, and rights separately.

PROV-O can model AI as a software agent; human accountability remains a governance decision.

PROV-O supports software agents, activities, associations, derivation, and attribution. It does not itself decide who should be accountable for a published synthesis.

In practice — Use contribution roles such as researched, synthesized, drafted, generated, and validated; identify the human who directed, reviewed, approved, and owns the work.

Part IV · Chapter 15

Advanced practice

Extensions for knowledge systems, AI-assisted work, provenance, and durable research.

knowledge

In the current OKF 0.1 draft, OKF is an interchange envelope rather than a complete epistemic model.

The draft standardizes a minimal Markdown, YAML, file-tree, index, log, link, and citation envelope while leaving domain schemas and typed relationship semantics to producers.

In practice — Use OKF for canonical authoring and exchange; add a versioned enterprise research profile, JSON Schema validation, and compiled JSON-LD semantics.

In okf-skills, durable knowledge, agent instructions, and agent memory serve different contracts.

The okf-skills implementation distinguishes shared curated knowledge from standing behavioral instructions and tool-specific implicit memory.

In practice — Keep research in the OKF bundle, agent behavior in skills or instruction files, and disposable session memory outside the source of truth.

The okf-skills implementation pairs agent authoring with deterministic conformance checks.

The implementation pairs agent authoring with a strict validator rather than relying on an agent to judge its own format compliance.

In practice — Validate reserved files, YAML parsing, required type fields, local schemas, IDs, internal links, citations, and generated derivatives in CI.

The okf-skills repository demonstrates a self-documenting operational feedback loop.

okf-skills documents its own skills, components, reference specification, and architectural decisions as an OKF bundle that is validated on change.

In practice — Store the communication research system in the same format it recommends and compile the SPA from that canonical bundle.

Part IV · Chapter 16

Reference library

The 92 sources behind the guide. Chips elsewhere link here; external links open the originals.

DIATAXIS

Diátaxis documentation framework

documentation framework

Reference as — Use distinct documentation forms for distinct user needs.

Reader intent and the separation of tutorials, how-to guides, reference, and explanation.

REDHAT-MODULAR

Red Hat modular documentation

documentation practice

Reference as — Modular content can be composed into different experiences.

Concept, procedure, and reference modules that answer bounded user questions.

WCAG-INFO-REL

WCAG 2.2: Info and Relationships

accessibility standard

Reference as — Presentation alone must not carry essential structure.

Semantic representation of structure and relationships.

HARVARD-ORGANIZING

Harvard: Organizing Your Essay

academic university

Reference as — A strong argument advances through explicit claims and subclaims.

Thesis decomposition, paragraph purpose, evidence, and analysis.

UNC-EVIDENCE

UNC: Evidence

academic university

Reference as — Evidence must match the kind of claim being made.

Discipline-appropriate forms of evidence and their use.

UNC-LIT-REVIEWS

UNC: Literature Reviews

academic university

Reference as — Organize existing work by themes, debates, methods, and gaps.

Literature reviews as synthesis rather than source-by-source summaries.

UNC-ARGUMENT

UNC: Argument

academic university

Reference as — Facts become arguments only when connected by reasoning.

Claims, evidence, reasoning, and counterargument.

GMU-IMRAD

George Mason: IMRaD Reports

academic university

Reference as — Separate observation from method and interpretation.

Introduction, methods, results, and discussion.

SWALES-CARS

Swales CARS model

academic primary

Reference as — Introductions should show importance, unresolved need, and contribution.

Establish territory, establish niche, occupy niche.

GOOGLE-HEADINGS

Google developer documentation: Headings

documentation practice

Reference as — Headings should expose purpose and structure.

Descriptive, unique, hierarchical headings.

GOOGLE-WORDS

Google technical writing: Words

documentation practice

Reference as — Local clarity improves human and machine interpretation.

Consistent terminology, explicit nouns, and restrained acronyms.

MONDAY-TECH-SPEC

Monday.com: Technical specification

technical practice

Reference as — Specifications must connect implementation to business and operations.

Functional versus technical specifications, rollout, security, support, and metrics.

ATLASSIAN-SDD

Atlassian: Software design document

technical practice

Reference as — Design documents are shared alignment and decision artifacts.

Architecture, interfaces, assumptions, dependencies, constraints, and trade-offs.

AMAZON-NARRATIVES

AWS: Product management at Amazon

enterprise practice

Reference as — Different narrative forms serve different organizational decisions.

Narrative mechanisms including PR/FAQ, reviews, readiness, and correction of error.

COGNITECT-ADR

Documenting Architecture Decisions

architecture framework

Reference as — Preserve why a decision was made, including negative consequences.

Context, decision, status, and consequences for significant architecture choices.

IEEE-42010

ISO/IEC/IEEE 42010 architecture descriptions

architecture standard

Reference as — One diagram cannot represent every architectural concern.

Stakeholders, concerns, viewpoints, and views.

C4 model

architecture framework

Reference as — Use progressive architectural zoom for different audiences.

Hierarchical system, container, component, and code views.

SPOTIFY-GOLDEN-PATHS

Spotify Golden Paths

platform practice

Reference as — Documentation works best when attached to supported product paths.

Supported journeys, tutorials, tooling, and platform enablement.

SPOTIFY-DOCS-AS-CODE

Spotify docs as code and Backstage

platform practice

Reference as — Documentation ownership should follow software ownership.

Documentation close to code and changed through engineering workflows.

NETFLIX-PAVED-ROADS

Netflix paved roads

platform practice

Reference as — Standardization requires productized enablement, not prose alone.

Supported practices and tools made easier than unsupported alternatives.

AIRBNB-VIADUCT

Airbnb Viaduct documentation

platform practice

Reference as — Organize platform docs by audience journey and lifecycle.

Role- and task-separated documentation, API reference, RFCs, and stability annotations.

AIRBNB-GRAPHQL

Airbnb: GraphQL data mocking with LLMs

llm practice

Reference as — Provide models only relevant context and validate output against authority.

Bounded relevant context, documentation, schema validation, and corrective retries.

AIRBNB-VOICE

Airbnb voice support retrieval

llm practice

Reference as — Retrieval systems require evaluation, not only generation quality.

Semantic retrieval, reranking, and retrieval-quality measurement.

NARRATIVE-TRANSPORT

Narrative transportation research

story review

Reference as — Story guides attention but can influence beyond evidence strength.

Attention, imagery, emotion, and immersion in narratives.

DATA-STORY-REVIEW

Data storytelling systematic review

story review

Reference as — Data storytelling is broader than a single narrative formula.

Narrative, visualization, cognition, and interaction in data storytelling.

ASSERTION-EVIDENCE

Assertion–evidence presentations

presentation university

Reference as — Slides should advance claims rather than display topic headings and bullet walls.

Complete-sentence assertions supported by visual evidence.

MAYER-MULTIMEDIA

Multimedia learning principles

presentation review

Reference as — Reduce extraneous processing and align related verbal and visual information.

Coherence, signaling, redundancy, and spatial/temporal contiguity.

AIDA

AIDA model review

marketing review

Reference as — AIDA is a drafting aid, not a universal linear decision model.

Attention, interest, desire, and action as a historical persuasion heuristic.

NNG-GET-STARTED

NN/g: Get Started links

marketing practice

Reference as — CTA labels should describe the consequence of action.

Generic CTAs can pull users into flows before they understand the offer.

MAILCHIMP-EMAIL

Mailchimp email marketing design

newsletter practice

Reference as — Email effectiveness must be tested with the actual audience.

Clear goal, concise content, CTA, responsive design, and testing.

FREEMIUM-VALUE

Freemium satisfaction and conversion research

marketing primary

Reference as — Premium value should add utility rather than gate basic understanding.

Perceived value and satisfaction in premium conversion.

MICROSOFT-PERSONAS

Microsoft personas in practice and theory

persona primary

Reference as — Personas should be maintained research infrastructure.

Foundation documents, traceability, scenarios, progressive disclosure, and revision.

PERSONA-QUANT-REVIEW

Review of quantitative persona creation

persona review

Reference as — Use qualitative discovery with quantitative validation where possible.

Rigor, scalability, objectivity, representation, and mixed methods.

CHAPMAN-MILHAM

Personas and verification critique

persona primary

Reference as — A concrete profile may not represent a measurable segment.

Verification, falsifiability, and population representation concerns.

PERSONA-QUANT-TEST

Quantitative test of persona specificity

persona primary

Reference as — Only include decision-relevant attributes.

Match rates decline as many attributes are combined.

PERSONA-STEREOTYPE

Persona stereotyping critique

persona primary

Reference as — Humanizing details can increase projection and exclusion.

Risks of simplification and stereotyping in persona representations.

NNG-REVISE-PERSONAS

NN/g: Revising personas

persona practice

Reference as — Use evidence-triggered review and versioning.

Personas drift as products, behavior, and environments change.

NNG-PERSONA-TYPES

NN/g: Persona types

persona practice

Reference as — Label the evidence maturity of every persona.

Proto-personas, qualitative personas, and statistically supported personas.

NNG-PERSONAS-ARCHETYPES

NN/g: Personas versus archetypes

persona practice

Reference as — Use the least fictional form that supports the decision.

Biographical representation versus abstract behavioral patterns.

WHO-ACTIONABLE

WHO actionable communication

persona practice

Reference as — Communication objectives should specify observable audience outcomes.

Audience knowledge, attitudes, behavior, barriers, and action.

IBM-RESEARCH-PLANNING

IBM research planning

research practice

Reference as — Persona research belongs inside a formal research plan.

Objectives, business goals, participant groups, recruitment, methods, and repositories.

NNG-PERSONA-FAIL

NN/g: Why personas fail

persona practice

Reference as — A persona poster without decision integration is decoration.

Scope, organizational embedding, and connection to decisions.

GOVUK-POLICY-PERSONAS

GOV.UK policy persona guidance

persona practice

Reference as — Represent affected people, not only interface users.

Substantial research, participation, observed facts, and continuing reevaluation.

ONS-PERSONAS

ONS content personas

persona practice

Reference as — Communication personas should emphasize knowledge and use context.

Audience grouping by expertise and task.

ATLASSIAN-BUYER-PERSONAS

Atlassian buyer personas

persona practice

Reference as — Buyer and product-use personas support different decisions.

Buying role, channels, trusted sources, goals, and barriers.

MICROSOFT-PERSONA-POWER

Microsoft: The power of personas

persona practice

Reference as — Do not use persona opinion when hard quantitative criteria are required.

Persona use boundaries and qualitative judgment.

GOVUK-RESEARCH-PRIVACY

GOV.UK participant privacy

research practice

Reference as — Separate restricted participant data from aggregated persona outputs.

Consent, data minimization, controlled access, and deletion.

LLM-PERSONA-REVIEW

Systematic review of LLM-generated personas

persona review

Reference as — Synthetic personas are hypotheses, not empirical participants.

Growth, evaluation gaps, and human oversight for synthetic personas.

LLM-PERSONA-VALIDITY

Persona prompting and subgroup validity

persona draft

Reference as — Do not treat simulated responses as user research.

Emerging evidence that persona conditioning may not reproduce population behavior.

ARISTOTLE-RHETORIC

Stanford Encyclopedia: Aristotle rhetoric

persuasion review

Reference as — Reasoning, credibility, and significance must reinforce one another.

Logos, ethos, and pathos in rhetorical persuasion.

ELM-REVIEW

Elaboration Likelihood Model review

persuasion review

Reference as — Layer enterprise decisions for both rapid orientation and substantive scrutiny.

Motivation, ability, elaboration, arguments, and cues.

SOURCE-CREDIBILITY

Source credibility research review

persuasion review

Reference as — Credibility applies per claim and context, not universally to a brand.

Credibility, ambiguity, expertise, and audience evaluation.

REACTANCE

Psychological reactance review

persuasion review

Reference as — Separate mandates from recommendations and preserve meaningful choice.

Resistance when freedom is perceived as threatened.

INOCULATION

Meta-analysis of inoculation theory

persuasion review

Reference as — Address credible objections before they become external attacks.

Exposure to counterarguments and refutations.

NARRATIVE-META

Narrative persuasion meta-analysis

persuasion review

Reference as — Use stories to make consequences concrete, then return to aggregate evidence.

Variation in narrative effects by audience, topic, medium, and familiarity.

FRAMING-REVIEW

Framing effects review

persuasion review

Reference as — Test recommendations in benefit, loss, cost, status-quo, and downside frames.

Judgments change across gain, loss, and reference-point frames.

UNCERTAINTY-TRUST

Uncertainty communication and trust

persuasion primary

Reference as — Explain uncertainty type, range, driver, and consequence.

Trust effects of explicit and quantified uncertainty.

PURDUE-TOULMIN

Purdue OWL: Toulmin argument

persuasion university

Reference as — Make practical reasoning inspectable and challengeable.

Claim, grounds, warrant, backing, qualifier, and rebuttal.

PURDUE-CLASSICAL

Purdue OWL: Classical argument

persuasion university

Reference as — Use a broad persuasive arc for strategic advocacy.

Context, position, proof, refutation, and conclusion.

PURDUE-ROGERIAN

Purdue OWL: Rogerian argument

persuasion university

Reference as — Use when legitimate enterprise interests are in tension.

Fair presentation of opposing positions and common ground.

POLICY-MEMO

Policy memo guidance

enterprise university

Reference as — Enterprise recommendations should be decision instruments, not generic essays.

Decision-maker focus, evidence, alternatives, feasibility, and recommendation.

AMAZON-DOORS

Amazon one-way and two-way doors

tradeoff practice

Reference as — Hard-to-reverse decisions deserve stronger evidence and review.

Decision-process intensity based on reversibility.

REAL-OPTIONS

Real options reasoning

tradeoff primary

Reference as — Evaluate which future choices an investment creates or closes.

Expansion, deferral, switching, and abandonment under uncertainty.

SEI-TECH-DEBT

SEI: Field study of technical debt

tradeoff primary

Reference as — Document principal, interest, benefit, trigger, and owner.

Short-term delivery versus future evolution and architectural debt.

PATH-DEPENDENCE

Technology path dependence

tradeoff primary

Reference as — Portability must be evaluated across data, API, skills, contracts, and operations.

Positive feedback, accumulated investment, and lock-in.

AMBIDEXTERITY

Organizational ambidexterity review

tradeoff review

Reference as — Separate mature operations from bounded experimentation and strategic learning.

Exploration versus exploitation and organizational structure.

FAIR

FAIR principles

stewardship framework

Reference as — Research needs identifiers, metadata, provenance, relationships, and licenses.

Findability, accessibility, interoperability, and reuse.

W3C-PROV

W3C PROV-O

stewardship standard

Reference as — Capture how research objects and outputs were generated.

Entities, activities, agents, derivation, attribution, and revision.

GOOGLE-AI-FEATURES

Google AI features and website content

retrieval practice

Reference as — No special AI markup replaces clear authoritative content.

Indexable, people-first, internally linked, textually available content.

GOOGLE-AI-OPT

Google guidance on AI and search content

retrieval practice

Reference as — Do not rewrite content into artificial machine-targeted keyword patterns.

Existing quality and SEO foundations for AI-mediated discovery.

RAG-CHUNKING

Structure-aware RAG chunking research

retrieval draft

Reference as — Chunk at semantic boundaries and validate against the actual corpus.

Hierarchical and structure-aware segmentation in retrieval systems.

LLM-ARCH-DOCS

LLM-generated architecture documentation

retrieval draft

Reference as — Use LLMs for transformation with technical validation and governance.

Emerging value and limitations of automated architecture documentation.

MEMENTO

RFC 7089 Memento

stewardship standard

Reference as — A URL alone is insufficient for durable evidence.

Time-based access to archived states of web resources.

DATASHEETS

Datasheets for Datasets

stewardship primary

Reference as — Apply structured documentation cards to research sources and syntheses.

Motivation, composition, collection, use, and limitations documentation.

NANOPUB

Nanopublication guidelines

stewardship framework

Reference as — Claims should be independently identifiable and citable.

Atomic assertions packaged with provenance and publication information.

AIF

Argument Interchange Format

stewardship primary

Reference as — Store the reasoning graph, not only the final recommendation.

Shared representation for structured arguments.

CITO

Citation Typing Ontology

stewardship primary

Reference as — Record why each source is cited.

Machine-readable citation intent such as supports, disputes, or extends.

WEB-ANNOTATION

W3C Web Annotation Data Model

stewardship standard

Reference as — Preserve source locators, quotations, and evidence relationships.

Annotations linked to exact text or resource segments.

RO-CRATE

RO-Crate specification and guidance

stewardship standard

Reference as — Use an open outer container for files, metadata, people, and software.

Lightweight JSON-LD research-object packaging.

ORCID

ORCID persistent researcher identifiers

stewardship standard

Reference as — Keep agent and human attribution stable over time.

Persistent identities for research contributors.

SWHID

Software Heritage persistent identifiers

stewardship standard

Reference as — Use hashes and stable logical IDs for exact artifact states.

Content-based persistent identifiers for software artifacts.

OKF-SPEC

Open Knowledge Format (OKF) Version 0.1 — Draft

Knowledge systems and provenance draft

Reference as — OKF defines a deliberately minimal interoperability envelope rather than a centrally registered domain ontology.

Canonical rules for bundles, concepts, frontmatter, cross-links, index files, logs, citations, conformance, and versioning.

OKF-GOOGLE-BLOG