Reader intent and information architecture
Orient, teach, help act, support decisions, enable verification, operate, persuade, and retrieve.
View findingsComprehensive research synthesis · Version 1.0 · 17 July 2026
A mobile-first, evidence-linked reference for academic research, technical documentation, architecture explanations, personas, storytelling, persuasion, business value, temporal trade-offs, presentations, marketing, newsletters, LLM retrieval, and future-agent research continuity.
The research compiler that turns durable knowledge into audience-specific communication.
The durable solution is not a better universal template. It is a governed communication system that stores research and reasoning independently from the articles, HTML explainers, presentations, specifications, newsletters, and LLM answers generated from it.
Orient, teach, help act, support decisions, enable verification, operate, persuade, and retrieve.
View findingsIMRaD, CARS, literature reviews, claim–evidence–analysis, method, results, and limitations.
View findingsClaims, evidence, warrants, backing, qualifiers, counterarguments, and confidence.
View findingsTutorials, how-to guides, reference, explanation, runbooks, specifications, ADRs, and lifecycle content.
View findingsStakeholder concerns, viewpoints, diagrams, narrative explanations, boundaries, and operational implications.
View findingsControlled change, data narrative, assertion–evidence slides, companion documents, and cognitive load.
View findingsCategory, relevance, value, proof, objections, specific CTA, recurring utility, and premium differentiation.
View findingsPopulations, segments, archetypes, situations, impact contracts, validation, ethics, and lifecycle.
View findingsLogos, ethos, pathos, elaboration, reactance, inoculation, framing, uncertainty, and argument structures.
View findingsNet value, beneficiary and cost bearer, reversibility, option value, debt, lock-in, and time horizons.
View findingsSemantic chunks, local context, reranking, validation, authoritative sources, and model-independent adapters.
View findingsAtomic research objects, provenance, source preservation, challenge records, evaluation suites, and open packaging.
View findingsOwners, status, review triggers, permitted use, prohibited use, success measures, and retirement.
View findingsThe rules that remain stable across document types, channels, and technologies.
Choose the reader task and decision before choosing a document, page, diagram, or deck.
Make source quality, applicability, uncertainty, and reasoning inspectable. Expertise is demonstrated through traceability.
Keep full evidence and provenance in the canonical layer. Publish progressively reduced views for each audience and channel.
Separate claims, concepts, evidence, decisions, examples, and procedures from individual output layouts.
Semantic headings, relationships, labels, and content boundaries serve humans, assistive technology, search, and retrieval systems.
Connect purpose, problem, evidence, causality, priority, choice, and accepted trade-offs before implementation detail.
Show what improves, what worsens, who benefits, who pays, and what future options are preserved or constrained.
Use personas only for declared decisions and contexts. Prefer behavioral evidence over invented biography.
Store claims, grounds, warrants, qualifiers, assumptions, rebuttals, alternatives, and decision criteria.
State what the audience should know, decide, do, verify, or explain after using an artifact.
Do not reserve semantic structure, inclusive participation, privacy, or persuasion integrity for final review.
Supersede claims and recommendations with an epistemic change log. Preserve rejected challenges and prior states.
Choose a genre by the reader contract, not by organizational habit.
Each form optimizes for a different type of work. The canonical facts may be shared, but the hierarchy, level of detail, evidence presentation, and call to action must change.
| Form | Use it for | Core structure | Do not use it as |
|---|---|---|---|
| Research note | Capture one observation, source, or question. | Question → observation → source → interpretation → follow-up | Not a final conclusion. |
| Annotated bibliography | Record what a source contributes and how reliable it is. | Citation → summary → quality → useful claims → limitations | Do not treat separate annotations as synthesis. |
| Literature review | Map existing knowledge, debates, methods, and gaps. | Scope → method → themes → agreement → conflict → gaps → implications | Do not organize only by source. |
| Research paper | Contribute an original argument, method, or result. | Introduction → method → results → discussion → limitations | Not an operational procedure. |
| Experiment or benchmark report | Make a test reproducible and its result bounded. | Hypothesis → environment → method → metrics → results → interpretation | Do not generalize beyond workload and environment. |
| Case study | Explain an intervention and outcome in context. | Context → problem → intervention → outcome → limits → transferable lesson | One case is not universal proof. |
| White paper | Educate and establish a defensible direction. | Problem → evidence → approach → value → implementation → next action | Do not present advocacy as independent academic evidence. |
| Executive brief | Enable a rapid consequential decision. | Decision → significance → evidence → options → recommendation → risk | Do not make the decision request implicit. |
| Narrative memo | Develop shared context and reasoning. | Situation → tension → evidence → alternatives → recommendation → consequences | Not ideal for primarily visual demonstrations. |
| Business case | Justify investment or prioritization. | Problem → strategic fit → options → net value → risk → recommendation | Do not count transferred costs as savings. |
| Proposal | Request permission, funding, or commitment. | Need → response → scope → deliverables → resources → risk → acceptance | Not a status report. |
| RFC | Collect broad review before a meaningful change. | Summary → motivation → design → alternatives → compatibility → rollout → open questions | Avoid for trivial local choices. |
| ADR | Preserve one significant architecture decision. | Context → decision → status → consequences → revisit conditions | Not a substitute for the complete system design. |
| PRD | Align on user and product outcomes. | Problem → goals → requirements → non-goals → measures → constraints | Do not bury technical implementation decisions inside product language. |
| Functional specification | Describe expected behavior. | Actors → scenarios → behavior → rules → errors → acceptance | Does not replace an implementation design. |
| Technical specification | Provide an implementation and operational blueprint. | Context → requirements → architecture → interfaces → security → operations → rollout | Premature when the solution remains exploratory. |
| Tutorial | Help a learner acquire competence. | Outcome → prerequisites → guided sequence → checkpoints → result → next step | Do not double as exhaustive reference. |
| How-to guide | Help a competent reader accomplish a task. | Goal → prerequisites → steps → expected result → recovery | Do not teach the whole conceptual domain. |
| Reference | Support exact lookup. | Definition → syntax → parameters → constraints → examples → errors | Do not force a learning journey. |
| Explanation | Build a mental model. | Definition → relationships → mechanism → examples → boundaries | Do not disguise procedures as theory. |
| Runbook | Support reliable operation and recovery. | Trigger → diagnosis → action → validation → escalation → rollback | Do not bury it in architecture prose. |
| Postmortem | Learn from an incident and improve controls. | Impact → timeline → causes → contributing conditions → actions → verification | Avoid blame and retrospective certainty. |
| Thought-leadership article | Establish a defensible point of view. | Thesis → context → evidence → synthesis → implications | 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 | Do not ask for conversion before understanding. |
| Newsletter | Deliver recurring signal and utility. | Issue thesis → findings → interpretation → links → action | Do not reproduce the entire research report. |
| Presentation | Guide a time-bound spoken argument. | Assertion → evidence → transition → decision | A deck is not the durable source of truth. |
| Policy | State mandatory organizational requirements and rationale. | Purpose → scope → requirements → responsibilities → exceptions → enforcement | Do not use should when must is intended. |
| Guideline | Provide context-sensitive recommended practice. | Context → recommendation → rationale → exceptions → examples | Do not make optional guidance appear mandatory. |
| Structure | Best use | Sequence | Benefit |
|---|---|---|---|
| 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. |
A document that tries to orient, teach, guide action, provide exact reference, justify a decision, market a product, and preserve research provenance in one visible hierarchy will usually underperform every one of those jobs. Share canonical objects; separate the views.
How to collect, evaluate, synthesize, argue, and preserve evidence.
Subject-matter expertise is demonstrated by making the boundary between known, inferred, recommended, and uncertain material visible.
| Class | Appropriate meaning |
|---|---|
| Standard | Normative requirement from a recognized standards body. |
| Systematic synthesis | Review or meta-analysis across multiple studies. |
| Primary research | Original study, experiment, benchmark, or empirical analysis. |
| University guidance | Research- and discipline-informed writing or method guidance. |
| Company practice | First-party documentation of a named organization’s implementation. |
| Framework | Reusable professional model that may not be universally empirical. |
| Our synthesis | A conclusion derived across several sources and enterprise constraints. |
| Hypothesis | A proposition requiring validation. |
| Subjective judgment | An editorial, visual, or strategic preference. |
For consequential recommendations, extend the unit with a warrant, backing, qualifier, counterargument, limitations, and a recommendation.
The order is contextual. A company engineering article is the primary source for that company’s implementation, but not necessarily strong evidence for a universal behavioral claim.
Research objective, intended decision, audiences, time horizon, scope, exclusions, terminology, evidence bar, and contested questions.
Search broadly; evaluate authority, method, relevance, recency, independence, reproducibility, applicability, and conflicts.
Capture claim supported, exact evidence, method, population, limitations, significance, contradictory findings, and exact source locator.
Group established principles, convergence, disagreement, context-dependent practice, emerging evidence, gaps, and enterprise implications.
Fact, citation, technical, adversarial, accessibility, readability, privacy, security, retrieval, and stakeholder review.
Compile audience-specific outputs; measure outcomes; define owner, review triggers, expiration, supersession, and archive policy.
From reader journeys to specifications, decisions, diagrams, operations, and lifecycle.
Documentation should be treated as a product with users, journeys, requirements, quality attributes, defects, analytics, operational ownership, release cycles, and deprecation.
| Layer | Required coverage |
|---|---|
| Control | ID, owner, status, reviewers, version, classification, last verified. |
| Context | Current state, user and business need, trigger, goals, non-goals, constraints, assumptions. |
| Architecture | Components, data lifecycle, interfaces, identity, authorization, trust boundaries, dependencies. |
| Quality | Security, privacy, compliance, accessibility, capacity, performance, resilience, disaster recovery. |
| Lifecycle | Testing, migration, rollout, rollback, observability, support, maintenance, ownership. |
| Decision | Alternatives, trade-offs, consequences, open questions, success measures, references. |
A diagram is a view, not the architecture. Every diagram declares intended audience, stakeholder concern, scope, abstraction level, time perspective, included and omitted elements, notation, source of truth, owner, and last verification.
| View | Question answered |
|---|---|
| Landscape | What systems and domains exist? |
| System context | Who and what interacts with the system? |
| Container | What deployable or executable units compose it? |
| Component | What responsibilities exist inside a unit? |
| Dynamic or sequence | What happens in a scenario? |
| Deployment | Where does software run? |
| Data flow and lineage | Where does information originate, transform, persist, and propagate? |
| Threat model | Where are trust boundaries, threats, controls, and residual risk? |
| Operational topology | How is the service observed, supported, scaled, and recovered? |
Research-backed audience models that guide communication without becoming persuasive fiction.
A persona is a versioned, evidence-backed representation of a decision-relevant behavioral pattern within a defined population, context, and period.
Enterprise work usually benefits from an archetype such as time-constrained service operator investigating an active production failure more than a named character with an invented age, photograph, family, and hobbies.
| Audience role | Communication concern |
|---|---|
| Primary consumer | The task that determines the artifact’s principal organization. |
| Decision maker | Evidence, consequences, alternatives, and decision criteria. |
| Implementer | Contracts, examples, failure behavior, acceptance, and migration. |
| Operator | Telemetry, ownership, failure, recovery, escalation, and support. |
| Reviewer or gatekeeper | Correctness, security, risk, compliance, funding, or procurement. |
| Affected party | Consequences experienced despite not directly using the artifact or system. |
| Future maintainer | Historical rationale, supersession, and reconstruction of context. |
| Adversarial actor | Ambiguity, weak controls, and exploitable assumptions. |
After consuming [artifact], members matching [persona and situation] should be able to [observable outcome] under [conditions] with [quality threshold], as measured by [indicator], without [dangerous interpretation or behavior].
Design recommendations as inspectable arguments that improve informed choice.
Enterprise persuasion should improve the quality of informed choice rather than merely increase agreement with the author.
Evidence, causal reasoning, financial analysis, architecture logic, trade-offs, assumptions, alternatives, and measures.
Accuracy, transparent uncertainty, fair alternatives, accountability, competence, independence, and verifiability.
Make customer harm, operator burden, risk, lost opportunity, confidence, and urgency tangible without exceeding the evidence.
Revenue, margin, avoided cost, cash flow, capital efficiency
Retention, satisfaction, availability, speed, trust
Throughput, reliability, recovery, support burden
Probability, impact, exposure, compliance, residual risk
Differentiation, time to market, option value, adaptability
Evolvability, interoperability, resilience, maintainability
Cognitive load, onboarding, productivity, retention
Evidence, reusable capability, institutional knowledge
Visibility, consistency, ownership, auditability
Partner integration, reuse, portability, standards alignment
Net value = benefits − direct costs − operating costs − transition costs − opportunity costs − risk exposure − future constraints.
Every value claim identifies outcome, beneficiary, mechanism, time horizon, measure, baseline, uncertainty, and cost bearer.
| Horizon | Questions |
|---|---|
| Immediate | Delivery, disruption, migration effort, decision overhead, and early failure. |
| Near term | Adoption, training, stability, initial value, and support burden. |
| Medium term | Operating cost, scaling, debt, organizational dependency, and measurement. |
| Long term | Strategic flexibility, architecture evolution, lock-in, and market or regulatory change. |
| Exit | Replacement, data portability, retained contracts, decommissioning, and restoration of the prior state. |
Outcome · evidence · beneficiary · cost bearer · time to value · duration · direct and opportunity cost · transition and operating cost · probability and impact · reversibility · option value · path dependency · technical debt · scalability · security · governance · distribution · confidence.
Atomic structures that can be mixed and matched without changing canonical facts.
These are assembly patterns. They specify hierarchy and decision purpose. They do not replace research, source assessment, editorial judgment, accessibility testing, or technical validation.
Select the correct communication form before authoring.
Synthesize a field without becoming a list of sources.
Preserve methodological inspectability.
Connect design to implementation, operations, and outcomes.
Make every diagram answer a declared concern.
Prevent a static profile from substituting for context.
Turn a persona into governed research infrastructure.
Define a measurable communication outcome.
Make a recommendation inspectable.
Explain why before how.
Enable a defensible enterprise choice.
Prevent short-term value from hiding future cost.
Build a deck around claims rather than topics.
Create reusable recurring intelligence.
Move from question to governed publication.
Enable reproduction, audit, red-team, and extension.
Challenge without silently rewriting history.
Render one knowledge base into many channels.
| Output | Lead with | Preserve elsewhere |
|---|---|---|
| Research article | Thesis, significance, method, thematic findings, implications. | Source registry, extraction notes, complete claim ledger. |
| Interactive SPA | Orientation, search, filters, progressive disclosure, stable anchors. | Embedded machine data, source details, version history, print view. |
| Presentation | Assertions, visual evidence, spoken sequence, decision. | Companion document, notes, appendix, citations, methods. |
| Executive memo | Decision, why now, recommendation, value, principal trade-off. | Technical design, calculations, evidence appendix. |
| Technical documentation | Reader task: learn, act, understand, look up, or recover. | Canonical concepts and contracts reused across views. |
| Newsletter | One signal, significance, evidence, action. | Canonical deep dive and source object. |
| Marketing page | Category, audience relevance, outcome, mechanism, proof, constraint, action. | Claim classification and substantiation record. |
| LLM response | Direct answer with local context, scope, evidence, and uncertainty. | Retrieved objects, prompt, citations, validation, and provenance. |
How research remains auditable, extensible, model-independent, and safe to transform.
Reproduce what the original researchers saw and did. Audit whether claims follow from evidence. Red-team errors, assumptions, omissions, and alternatives. Extend the work without erasing the prior state.
Source paper or operational evidence
└─ supports / disputes / qualifies → Claim
└─ connected by → Warrant and assumptions
└─ compared through → Options and trade-offs
└─ generates → Recommendation or decision
└─ assembled for → Persona + situation + impact contract
└─ renders → Article / SPA / deck / spec / newsletter / RAG unit
└─ produces → Measured audience and business outcomes
└─ triggers → Challenge / revision / supersessionenterprise-communication-research/
├── README.md
├── ro-crate-metadata.json
├── manifest.json
├── research-agenda/
├── sources/
│ ├── registry.yaml
│ ├── assessments/
│ ├── snapshots/
│ └── annotations/
├── knowledge/
│ ├── concepts/
│ ├── claims/
│ ├── evidence/
│ ├── warrants/
│ ├── assumptions/
│ ├── limitations/
│ └── recommendations/
├── audiences/
├── deliberation/
├── outputs/
├── challenges/
├── evaluations/
├── provenance/
└── schemas/id: claim-content-modularity-001
object_type: claim
canonical_statement: >
Content organized as bounded semantic modules can be assembled
into multiple audience- and task-specific outputs.
status: verified
evidence_class: company-practice
confidence: medium
scope:
domains: [technical-documentation, enterprise-knowledge]
exclusions: [literary-long-form]
evidence:
supporting:
- source_id: REDHAT-MODULAR
relation: supports
- source_id: DIATAXIS
relation: corroborates
warrant: >
Separating reusable knowledge from a page layout permits controlled
recombination without changing the underlying claim.
limitations:
- Modules still require editorial assembly and connective context.
- Excessive fragmentation can damage narrative coherence.
provenance:
created_at: 2026-07-17
last_verified_at: 2026-07-17
governance:
owner: platform-content
review_cycle_days: 180id: persona-platform-adopter-001
object_type: persona
version: 2.1
status: active
label: Pragmatic platform adopter
scope:
decision_domain: [platform-adoption, technical-documentation]
prohibited_uses: [market-sizing, access-control, performance-evaluation]
research_basis:
methods: [interviews, architecture-review-analysis, support-analysis]
sample:
participants: 18
limitations: [overrepresentation-of-early-adopters]
behavioral_model:
primary_goal: Adopt a maintainable integration without losing control.
primary_tension: Standardization helps, but opaque abstraction creates risk.
decision_criteria: [reliability, observability, migration-effort, security, reversibility]
evidence_preference: [measured-results, explicit-contracts, failure-scenarios]
communication_contract:
baseline: {knowledge: moderate, trust: skeptical}
desired_impact:
understand: [ownership-boundaries, routing-and-failure-model]
decide: [whether-to-run-pilot]
act: [complete-migration-assessment]
prohibited_messaging: [seamless, zero-risk, eliminates-lock-in]
validation:
unresolved_questions: [prevalence, regulated-team-differences]id: argument-ai-gateway-default-001
object_type: argument
claim: Adopt a shared AI gateway as the default model-access path.
grounds:
- Teams duplicate provider authentication, logging, retry, policy, and reporting.
warrant: >
Capabilities repeated across services can be governed and maintained more
consistently as a supported platform capability.
backing:
- internal-duplication-analysis
- incident-history
- platform-engineering-research
qualifier: >
Applies to standard inference workloads within the measured latency envelope.
rebuttal:
- Unsupported provider capabilities may justify direct integration.
- Hard real-time or legally isolated workloads may require exceptions.
assumptions:
- The platform has funded operational ownership.
- Emergency bypass and rollback are tested.
status: proposedid: challenge-persuasive-essay-004
object_type: challenge
type: overgeneralization
target:
claim_id: claim-narrative-persuasion-002
version: 1.1.0
challenge: >
The cited evidence contains consumer and health communication studies;
direct enterprise transfer is not yet established.
basis: [scope-mismatch, missing-enterprise-validation]
severity: medium
status: open
proposed_resolution: [narrow-scope, add-enterprise-study, label-transfer-inference]
raised_by:
agent: future-model-id
date: 2027-08-11research_handoff:
title: Enterprise Communication Research System
version: 1.0.0
status: active-research
last_reviewed: 2026-07-17
purposes: [preserve, reproduce, audit, red-team, expand]
start_here:
human: README.md
agent: manifests/agent-entry.yaml
source_of_truth:
claims: knowledge/claims/
sources: sources/
provenance: provenance/
decisions: deliberation/decisions/
known_weaknesses:
- limited non-Western rhetoric research
- incomplete empirical evaluation of enterprise persona impact
- limited longitudinal measurement of documentation outcomes
prohibited_agent_behavior:
- do not delete prior claims
- do not convert inference to fact
- do not upgrade confidence without evidence
- do not silently repair citations
required_agent_outputs:
- findings
- citations
- contradictions
- proposed_changes
- confidence
- provenance_recordid: architecture-article-ai-gateway
object_type: output-manifest
output_type: long-form-technical-article
purpose: {primary: explain, secondary: [build-confidence, support-decision]}
audience_constellation:
primary_persona: persona-platform-adopter-001
secondary_personas: [persona-security-reviewer-002, persona-platform-leader-003]
affected_profiles: [production-operations, application-support]
situations: [evaluating-adoption, preparing-architecture-review]
content_rules:
define: [semantic-routing, provider-fallback]
evidence_required: [architecture-contract, security-control-map, measured-latency]
objections_to_address: [lock-in, debuggability, central-failure]
prohibited_claims: [zero-latency, eliminates-provider-lock-in]
hierarchy: [problem, operating-model, architecture, evidence, failure, adoption]
primary_cta: run-readiness-assessment
measurement:
comprehension: [responsibility-model-score]
decision: [assessment-completion]
guardrail: [critical-security-misinterpretation-rate]The operating controls required to keep research authoritative and useful.
Verify sources, versions, hashes, quotations, dates, citation attachment, and retraction or correction status.
Test whether each source directly supports the claim and whether scope, causality, and applicability were exaggerated.
Challenge warrants, assumptions, qualifiers, counterarguments, logical dependencies, and hidden value judgments.
Add status quo, hybrid, phased, build, buy, defer, and abandon options where credible.
Expose transferred costs, affected stakeholders, uncertainty, reversibility, option value, debt, and lock-in over time.
Identify missing personas, affected parties, accessibility constraints, privacy issues, and coercive persuasion.
Find superseded standards, new research, changed enterprise practices, and append a versioned new synthesis.
| Test | What better performance means |
|---|---|
| Citation fidelity | Correctly distinguishes direct support, partial support, context, dispute, and no relationship. |
| Claim calibration | Narrows or qualifies a claim until it matches the evidence. |
| Argument completion | Identifies missing warrant, assumption, qualifier, or rebuttal. |
| Trade-off completeness | Finds omitted costs, beneficiaries, affected parties, horizons, and exit obligations. |
| Persona rendering | Changes hierarchy and explanation without changing canonical facts. |
| Temporal update | Compares old and new evidence, preserves history, and proposes a versioned change. |
| Adversarial synthesis | Produces the strongest evidence-based case against the current recommendation. |
| Hallucination resistance | Links factual assertions to existing claims and source objects or marks them unsupported. |
Findability · search success · time to answer · comprehension · decision accuracy · task completion · error rate · confidence calibration · accessibility outcome · support deflection · adoption · operational reliability · conversion · internal reuse · citation reuse · freshness · correction rate · retrieval precision.
Engagement is not task success. More clicks or time may indicate interest, confusion, or unnecessary effort. Measure the outcome declared in the impact contract.
Searchable, evidence-linked conclusions with enterprise implications.
The strongest artifact aligns reader intent, evidence strength, decision purpose, information architecture, and delivery medium.
Enterprise implication: Declare purpose, audience, decision, and intended action before drafting.
Tutorials, references, decision memos, specifications, and marketing pages optimize for different questions.
Enterprise implication: Use shared canonical knowledge with separate task-specific views.
Depth belongs in the source layer; progressive disclosure determines what each reader sees first.
Enterprise implication: Preserve full research and publish bounded views.
Paragraphs and sections should advance a claim, explain a concept, provide evidence, support action, or preserve context.
Enterprise implication: Remove or relocate units that serve no declared purpose.
Background alone does not establish why new work is needed.
Enterprise implication: Use territory, niche, and contribution moves.
Readers need to inspect how evidence was produced before accepting conclusions.
Enterprise implication: Use IMRaD for experiments, benchmarks, surveys, and formal evaluations.
Source-by-source summaries transfer analytical work to the reader.
Enterprise implication: Organize agreement, disagreement, methods, limitations, gaps, and implications.
Standards, experiments, company practices, and professional heuristics support different kinds of conclusions.
Enterprise implication: Label evidence class, scope, confidence, and limitations.
The source may provide context, a method, partial support, or direct contradiction.
Enterprise implication: Record citation intent and exact source locators.
Evidence does not determine a recommendation without a rule connecting observation to action.
Enterprise implication: Store warrants, backing, qualifiers, and rebuttals as first-class objects.
It has users, journeys, quality attributes, analytics, defects, ownership, release cycles, and deprecation.
Enterprise implication: Assign product ownership, measurement, and lifecycle controls.
Tool-oriented inventories do not necessarily help people complete enterprise work.
Enterprise implication: Organize platform content around Golden Paths, paved roads, and bounded tasks.
Security, privacy, data, performance, failure, observability, rollout, rollback, support, and measures define enterprise readiness.
Enterprise implication: Adopt a complete specification standard with explicit non-goals and alternatives.
A system design changes; the reasons behind significant choices remain important for future maintainers.
Enterprise implication: Record context, options, decision, consequences, risks, and revisit conditions.
Different concerns require different abstractions, notation, and scope.
Enterprise implication: Declare audience, concern, scope, omissions, legend, and last verification.
Lines and boxes do not reliably communicate ownership, trust, failure, causality, or rationale.
Enterprise implication: Explain purpose, reading order, flows, boundaries, decisions, failures, and operational implications.
Excessive component or code detail can obscure enterprise boundaries and responsibilities.
Enterprise implication: Start at the highest useful abstraction and add detail only for an explicit question.
A useful narrative connects an initial state, goal, tension, choice, changed state, and implication.
Enterprise implication: Use narrative to guide attention, then reconnect the case to aggregate evidence.
Narratives can be memorable enough to overpower base rates and broader data.
Enterprise implication: Label examples as illustrative and pair them with measured frequency or scope.
Dense slides compete with narration and are difficult to reuse independently.
Enterprise implication: Use assertion–evidence slides with notes, appendices, and a companion source document.
Demonstrated outcomes, customer reports, projections, capabilities, and aspirations have different epistemic status.
Enterprise implication: Classify every external claim before publication.
Generic labels can move readers into flows before they understand the consequence.
Enterprise implication: Use action-specific labels appropriate to audience authority and readiness.
A list of new content does not create sustained utility.
Enterprise implication: Lead with a signal, explain significance, provide evidence, and use one primary action.
Gating basic understanding weakens trust and does not establish durable premium value.
Enterprise implication: Monetize depth, proprietary data, tools, benchmarks, support, and customization.
It is not an average user, demographic stereotype, role, or real participant.
Enterprise implication: State population, decision domain, situation, confidence, and prohibited uses.
Combining many details can create an improbable composite that matches few real people.
Enterprise implication: Include only attributes that materially change a decision or communication need.
Names, photographs, and lifestyle details may improve memory while increasing projection and stereotyping.
Enterprise implication: Prefer archetypes and behavioral labels for enterprise work.
The same senior engineer has different needs while learning, troubleshooting, approving, or presenting.
Enterprise implication: Use a Persona Stack: population → segment → persona → situation → baseline → impact.
Implementers, approvers, operators, reviewers, affected parties, and future maintainers often have conflicting concerns.
Enterprise implication: Define one primary reading path and layered secondary views.
“Inform the audience” is neither observable nor testable.
Enterprise implication: Specify baseline, desired knowledge, decision, behavior, evidence threshold, guardrails, and measure.
Observed, reported, measured, inferred, hypothesized, and illustrative data have different validity.
Enterprise implication: Maintain an attribute-level evidence matrix.
Recruiting only people who fit an existing profile cannot reveal missing segments or invalid assumptions.
Enterprise implication: Include contrast cases, holdout samples, disconfirming evidence, and participants who fit none.
Models can generate plausible language without reproducing population behavior or prevalence.
Enterprise implication: Label synthetic output as hypothesis and validate with real participants and operational data.
Saying “the persona needs this” can erase the actual sample and variation.
Enterprise implication: Report participant findings first, then link the bounded synthesis.
The purpose is not agreement at any cost; it is a defensible decision made with material evidence and consequences visible.
Enterprise implication: Evaluate persuasive effectiveness and epistemic integrity separately.
Reasoning establishes defensibility, credibility establishes trust, and consequence establishes significance.
Enterprise implication: Let emotional force remain proportional to evidence strength.
Decision-makers may scan rapidly but consequential decisions require substantive scrutiny.
Enterprise implication: Lead with decision, stakes, strongest evidence, and trade-off; preserve full methods and analysis.
Expertise about one product or method does not guarantee independence or applicability elsewhere.
Enterprise implication: Assess competence, integrity, independence, accountability, verifiability, relevance, and currency.
Mandates, artificial inevitability, and suppression of alternatives threaten perceived autonomy.
Enterprise implication: Separate mandatory constraints from recommendations, preserve exceptions, and explain reversibility.
Inoculation and prebunking expose the audience to objections and reasoned responses.
Enterprise implication: Steelman predictable counterarguments and define conditions where they are valid.
Gain, loss, cost, status-quo, and downside frames activate different reference points.
Enterprise implication: Evaluate every material option through multiple equivalent frames.
Vague uncertainty is less useful than a range, cause, sensitivity, and operational consequence.
Enterprise implication: Separate measurement, forecast, implementation, market, and behavioral uncertainty.
Claims are conditional; warrants, qualifiers, and rebuttals determine whether a recommendation actually follows.
Enterprise implication: Expose the complete argument map.
Security versus speed and standardization versus autonomy can both contain valid interests.
Enterprise implication: Identify shared goals and create bounded defaults with explicit escape conditions.
Revenue and labor savings omit customer, operational, strategic, technical, workforce, risk, governance, and learning outcomes.
Enterprise implication: Use a complete value model and name the beneficiary.
A capability is not automatically an outcome. Every link from technical change to business consequence needs evidence or a labeled hypothesis.
Enterprise implication: Store outcome → beneficiary → mechanism → measure → baseline → horizon → uncertainty.
A proposal may save application-team time while increasing platform, operations, security, procurement, or future-maintainer burden.
Enterprise implication: Name both beneficiary and cost bearer.
Transition disruption, near-term adoption, medium-term operating cost, long-term lock-in, and exit obligations are different analyses.
Enterprise implication: Evaluate immediate, near, medium, long, and exit horizons.
A decision can be technically undoable yet economically, contractually, or politically locked in.
Enterprise implication: Estimate exit time, retained obligations, lost data, retraining, and dependency unwinding.
Pilots, interfaces, dual-run capability, export paths, and stop/go milestones preserve future choices.
Enterprise implication: Ask what later decisions become easier or harder.
The metaphor is useful only when the shortcut, benefit, principal, interest, owner, and repayment trigger are explicit.
Enterprise implication: Do not use technical debt as a generic label for disliked code.
Data export alone does not address API, identity, telemetry, skill, contract, process, and organizational lock-in.
Enterprise implication: Assess switching cost across every dependency dimension.
Speculative learning cannot be governed only by the utilization and predictability metrics of mature operations.
Enterprise implication: Classify investments as core scale, experiment, option creation, maintenance, or debt repayment.
Descriptive headings, bounded topics, explicit entities, local context, citations, dates, and versions support both people and retrieval.
Enterprise implication: Design semantic content units before embedding or indexing them.
Current search guidance does not require special AI-only schemas in place of people-first content and established indexing foundations.
Enterprise implication: Make claims distinctive, indexable, verifiable, internally linked, and textually available.
Fixed character windows can split claims from context, evidence, limitations, or procedures.
Enterprise implication: Use concepts, claims, decisions, procedures, failure modes, and examples as retrieval units.
Pronouns and references such as “this approach” lose meaning when isolated.
Enterprise implication: Use explicit nouns, defined terms, source IDs, scope, and limitations inside each unit.
Large undifferentiated inputs increase noise and can reduce model performance.
Enterprise implication: Retrieve bounded evidence, rerank it, and validate generated output against authority.
Models can classify, summarize, restructure, and generate alternate views while introducing unsupported facts or losing boundaries.
Enterprise implication: Validate citations, technical facts, dates, policies, and schemas before publication.
A final article hides the source graph, reasoning, unresolved questions, and rejected alternatives.
Enterprise implication: Store sources, claims, evidence, warrants, assumptions, recommendations, challenges, and outputs independently.
Future reviewers need to distinguish support, dispute, method reuse, extension, and background.
Enterprise implication: Type each citation relationship.
Document-level references force later agents to rediscover the passage and may invite unsupported paraphrase.
Enterprise implication: Store quotation selectors, prefixes, suffixes, page or section, and associated claim.
Future researchers need to know which model, prompt, retrieval set, tools, and human review generated a transformation.
Enterprise implication: Represent sources, activities, agents, derivations, approvals, and rejections.
A future model should not require the current vendor, context-window design, or proprietary application.
Enterprise implication: Use Markdown, JSON/YAML with schemas, JSON-LD, CSV/Parquet, text diagrams, IDs, hashes, and tests.
A more capable model should demonstrate citation fidelity, claim calibration, argument completion, trade-off completeness, persona consistency, and temporal updating.
Enterprise implication: Store test cases with expected criteria, not one frozen answer.
Must, should, may, and can communicate different authority. Ambiguity creates implementation and audit failures.
Enterprise implication: Define normative terms and separate policy, standard, procedure, and guideline.
Clicks and time can signal interest, confusion, or friction.
Enterprise implication: Measure comprehension, decision accuracy, task completion, error, retrieval, confidence calibration, and accessibility.
Enterprise decisions are made under bounded evidence and changing environments.
Enterprise implication: Define assumptions, success thresholds, stop conditions, rollback, and review triggers.
Prioritized actions for building a durable enterprise communication and research platform.
P0 establishes integrity and canonical structure. P1 operationalizes the research and communication system. P2 adds argument-aware retrieval, conflicting review agents, formal evaluation, and interoperable packaging.
Store sources, claims, evidence, concepts, assumptions, limitations, decisions, challenges, audiences, and outputs separately.
Every material factual claim needs an evidence class, exact source relationship, scope, confidence, limitations, and last verification.
A recommendation without explicit reasoning cannot be reliably audited or red-teamed.
Define the primary consumer, decision maker, implementer, operator, reviewer, affected party, and intended measurable outcome.
Use status, owner, semantic version, content hash, supersession, review trigger, and epistemic change log.
No recommendation may conceal material alternatives, negative consequences, uncertainty, cost transfer, or evidence limitations.
Use real headings, labels, tables, relationships, keyboard paths, readable contrast, and non-color cues in every output.
Store canonical and archive URLs, retrieval date, version, hash, license, and passage-level annotations.
Frame, collect, assess, extract, synthesize, validate, publish, measure, and maintain.
Determine whether the primary need is orientation, learning, action, decision, verification, operation, persuasion, or retrieval.
Include goals, non-goals, architecture, data, security, failure, observability, capacity, testing, migration, rollout, rollback, ownership, alternatives, and measures.
Each view declares audience, concern, scope, abstraction, omissions, notation, source, owner, and date.
Maintain operational card, foundation document, evidence matrix, scenarios, impact contracts, and lifecycle record.
Recruit contrast cases, allow people to fit multiple or no personas, and validate against holdout and operational data.
Expose claim, grounds, warrant, backing, qualifier, rebuttal, assumptions, and alternatives.
Identify beneficiary, mechanism, measure, baseline, uncertainty, direct cost, operating cost, transition cost, opportunity cost, and cost bearer.
Evaluate immediate, near, medium, long-term, and exit effects, including reversibility, option value, debt, and lock-in.
Make each slide advance a claim with visual evidence and retain a companion source document.
Each item contains a finding, significance, evidence, interpretation, action, and canonical deep link.
Distinguish demonstrated outcome, customer report, internal measurement, model, capability, aspiration, and opinion.
Chunk by claim, concept, decision, procedure, example, failure mode, and evidence discussion—not fixed character count alone.
Check source existence, citation support, dates, technical contracts, normative language, and schema validity.
Future agents should append criticism, severity, basis, evidence, status, and proposed resolution.
Use canonical objects plus persona and output manifests to generate articles, SPAs, decks, specs, newsletters, and retrieval chunks.
Retrieve claims with grounds, warrants, scope, limitations, counterarguments, and source annotations.
Separate evidence auditor, methodologist, argument critic, strategist, architect, security reviewer, operator, persona advocate, and historian.
Test citation fidelity, claim calibration, argument completion, trade-off completeness, persona consistency, temporal updates, and hallucination resistance.
Record model, version, prompt, retrieval inputs, tool outputs, date, reviewer, accepted changes, rejected changes, and known failures.
Link exact source passages to claims and state whether a citation supports, disputes, extends, or provides method or background.
Show how recommendations change under volume, cost, regulation, adoption, failure, and time-horizon assumptions.
Bundle README, manifest, source registry, schemas, research objects, provenance, challenges, outputs, evaluations, and changelog.
Patterns that make communication look complete while weakening accuracy, usability, or long-term value.
Evidence grouped by concept with guidance for how each source should be used.
DIATAXISDiátaxis documentation frameworkReader intent and the separation of tutorials, how-to guides, reference, and explanation.FrameworkREDHAT-MODULARRed Hat modular documentationConcept, procedure, and reference modules that answer bounded user questions.PracticeGOOGLE-HEADINGSGoogle developer documentation: HeadingsDescriptive, unique, hierarchical headings.PracticeGOOGLE-WORDSGoogle technical writing: WordsConsistent terminology, explicit nouns, and restrained acronyms.PracticeWCAG-INFO-RELWCAG 2.2: Info and RelationshipsSemantic representation of structure and relationships.StandardHARVARD-ORGANIZINGHarvard: Organizing Your EssayThesis decomposition, paragraph purpose, evidence, and analysis.UniversityUNC-EVIDENCEUNC: EvidenceDiscipline-appropriate forms of evidence and their use.UniversityUNC-LIT-REVIEWSUNC: Literature ReviewsLiterature reviews as synthesis rather than source-by-source summaries.UniversityUNC-ARGUMENTUNC: ArgumentClaims, evidence, reasoning, and counterargument.UniversityGMU-IMRADGeorge Mason: IMRaD ReportsIntroduction, methods, results, and discussion.UniversitySWALES-CARSSwales CARS modelEstablish territory, establish niche, occupy niche.PrimaryMONDAY-TECH-SPECMonday.com: Technical specificationFunctional versus technical specifications, rollout, security, support, and metrics.PracticeATLASSIAN-SDDAtlassian: Software design documentArchitecture, interfaces, assumptions, dependencies, constraints, and trade-offs.PracticeAMAZON-NARRATIVESAWS: Product management at AmazonNarrative mechanisms including PR/FAQ, reviews, readiness, and correction of error.PracticePOLICY-MEMOPolicy memo guidanceDecision-maker focus, evidence, alternatives, feasibility, and recommendation.UniversityCOGNITECT-ADRDocumenting Architecture DecisionsContext, decision, status, and consequences for significant architecture choices.FrameworkIEEE-42010ISO/IEC/IEEE 42010 architecture descriptionsStakeholders, concerns, viewpoints, and views.StandardC4C4 modelHierarchical system, container, component, and code views.FrameworkSPOTIFY-GOLDEN-PATHSSpotify Golden PathsSupported journeys, tutorials, tooling, and platform enablement.PracticeSPOTIFY-DOCS-AS-CODESpotify docs as code and BackstageDocumentation close to code and changed through engineering workflows.PracticeNETFLIX-PAVED-ROADSNetflix paved roadsSupported practices and tools made easier than unsupported alternatives.PracticeAIRBNB-VIADUCTAirbnb Viaduct documentationRole- and task-separated documentation, API reference, RFCs, and stability annotations.PracticeAIRBNB-GRAPHQLAirbnb: GraphQL data mocking with LLMsBounded relevant context, documentation, schema validation, and corrective retries.PracticeAIRBNB-VOICEAirbnb voice support retrievalSemantic retrieval, reranking, and retrieval-quality measurement.PracticeNARRATIVE-TRANSPORTNarrative transportation researchAttention, imagery, emotion, and immersion in narratives.ReviewDATA-STORY-REVIEWData storytelling systematic reviewNarrative, visualization, cognition, and interaction in data storytelling.ReviewASSERTION-EVIDENCEAssertion–evidence presentationsComplete-sentence assertions supported by visual evidence.UniversityMAYER-MULTIMEDIAMultimedia learning principlesCoherence, signaling, redundancy, and spatial/temporal contiguity.ReviewAIDAAIDA model reviewAttention, interest, desire, and action as a historical persuasion heuristic.ReviewNNG-GET-STARTEDNN/g: Get Started linksGeneric CTAs can pull users into flows before they understand the offer.PracticeFREEMIUM-VALUEFreemium satisfaction and conversion researchPerceived value and satisfaction in premium conversion.PrimaryMAILCHIMP-EMAILMailchimp email marketing designClear goal, concise content, CTA, responsive design, and testing.PracticeNNG-NEWSLETTERNN/g email newsletter designLong-running research on subjects, preheaders, content, voice, links, mobile, and subscription.ReviewMICROSOFT-PERSONASMicrosoft personas in practice and theoryFoundation documents, traceability, scenarios, progressive disclosure, and revision.PrimaryPERSONA-QUANT-REVIEWReview of quantitative persona creationRigor, scalability, objectivity, representation, and mixed methods.ReviewCHAPMAN-MILHAMPersonas and verification critiqueVerification, falsifiability, and population representation concerns.PrimaryPERSONA-QUANT-TESTQuantitative test of persona specificityMatch rates decline as many attributes are combined.PrimaryPERSONA-STEREOTYPEPersona stereotyping critiqueRisks of simplification and stereotyping in persona representations.PrimaryNNG-REVISE-PERSONASNN/g: Revising personasPersonas drift as products, behavior, and environments change.PracticeNNG-PERSONA-TYPESNN/g: Persona typesProto-personas, qualitative personas, and statistically supported personas.PracticeNNG-PERSONAS-ARCHETYPESNN/g: Personas versus archetypesBiographical representation versus abstract behavioral patterns.PracticeWHO-ACTIONABLEWHO actionable communicationAudience knowledge, attitudes, behavior, barriers, and action.PracticeNNG-PERSONA-FAILNN/g: Why personas failScope, organizational embedding, and connection to decisions.PracticeGOVUK-POLICY-PERSONASGOV.UK policy persona guidanceSubstantial research, participation, observed facts, and continuing reevaluation.PracticeONS-PERSONASONS content personasAudience grouping by expertise and task.PracticeATLASSIAN-BUYER-PERSONASAtlassian buyer personasBuying role, channels, trusted sources, goals, and barriers.PracticeMICROSOFT-PERSONA-POWERMicrosoft: The power of personasPersona use boundaries and qualitative judgment.PracticeLLM-PERSONA-REVIEWSystematic review of LLM-generated personasGrowth, evaluation gaps, and human oversight for synthetic personas.ReviewLLM-PERSONA-VALIDITYPersona prompting and subgroup validityEmerging evidence that persona conditioning may not reproduce population behavior.EmergingIBM-RESEARCH-PLANNINGIBM research planningObjectives, business goals, participant groups, recruitment, methods, and repositories.PracticeGOVUK-RESEARCH-PRIVACYGOV.UK participant privacyConsent, data minimization, controlled access, and deletion.StandardARISTOTLE-RHETORICStanford Encyclopedia: Aristotle rhetoricLogos, ethos, and pathos in rhetorical persuasion.ReviewELM-REVIEWElaboration Likelihood Model reviewMotivation, ability, elaboration, arguments, and cues.ReviewSOURCE-CREDIBILITYSource credibility research reviewCredibility, ambiguity, expertise, and audience evaluation.ReviewREACTANCEPsychological reactance reviewResistance when freedom is perceived as threatened.ReviewINOCULATIONMeta-analysis of inoculation theoryExposure to counterarguments and refutations.ReviewNARRATIVE-METANarrative persuasion meta-analysisVariation in narrative effects by audience, topic, medium, and familiarity.ReviewFRAMING-REVIEWFraming effects reviewJudgments change across gain, loss, and reference-point frames.ReviewUNCERTAINTY-TRUSTUncertainty communication and trustTrust effects of explicit and quantified uncertainty.PrimaryPURDUE-TOULMINPurdue OWL: Toulmin argumentClaim, grounds, warrant, backing, qualifier, and rebuttal.UniversityPURDUE-CLASSICALPurdue OWL: Classical argumentContext, position, proof, refutation, and conclusion.UniversityPURDUE-ROGERIANPurdue OWL: Rogerian argumentFair presentation of opposing positions and common ground.UniversityAMAZON-DOORSAmazon one-way and two-way doorsDecision-process intensity based on reversibility.PracticeREAL-OPTIONSReal options reasoningExpansion, deferral, switching, and abandonment under uncertainty.PrimarySEI-TECH-DEBTSEI: Field study of technical debtShort-term delivery versus future evolution and architectural debt.PrimaryPATH-DEPENDENCETechnology path dependencePositive feedback, accumulated investment, and lock-in.PrimaryAMBIDEXTERITYOrganizational ambidexterity reviewExploration versus exploitation and organizational structure.ReviewFAIRFAIR principlesFindability, accessibility, interoperability, and reuse.StandardW3C-PROVW3C PROV-OEntities, activities, agents, derivation, attribution, and revision.StandardMEMENTORFC 7089 MementoTime-based access to archived states of web resources.StandardDATASHEETSDatasheets for DatasetsMotivation, composition, collection, use, and limitations documentation.PrimaryNANOPUBNanopublication guidelinesAtomic assertions packaged with provenance and publication information.FrameworkAIFArgument Interchange FormatShared representation for structured arguments.PrimaryCITOCitation Typing OntologyMachine-readable citation intent such as supports, disputes, or extends.PrimaryWEB-ANNOTATIONW3C Web Annotation Data ModelAnnotations linked to exact text or resource segments.StandardRO-CRATERO-Crate specification and guidanceLightweight JSON-LD research-object packaging.StandardORCIDORCID persistent researcher identifiersPersistent identities for research contributors.StandardSWHIDSoftware Heritage persistent identifiersContent-based persistent identifiers for software artifacts.StandardGOOGLE-AI-FEATURESGoogle AI features and website contentIndexable, people-first, internally linked, textually available content.PracticeGOOGLE-AI-OPTGoogle guidance on AI and search contentExisting quality and SEO foundations for AI-mediated discovery.PracticeRAG-CHUNKINGStructure-aware RAG chunking researchHierarchical and structure-aware segmentation in retrieval systems.EmergingLLM-ARCH-DOCSLLM-generated architecture documentationEmerging value and limitations of automated architecture documentation.EmergingThe visible interface and embedded data share the same research model.
The page contains structured metadata, principles, domains, genres, structures, findings, playbooks, recommendations, anti-patterns, value dimensions, object types, schemas, reference records, and future-agent handoff rules.
document.getElementById('research-data').textContent
{
"metadata": {
"title": "Enterprise Communication Research System",
"version": "1.0.0",
"status": "Living research synthesis",
"generated": "2026-07-17",
"description": "A canonical research and communication system for technical documentation, academic research, architecture communication, personas, persuasion, business value, trade-offs, LLM retrieval, and future-agent stewardship.",
"method": "Synthesis of standards, university guidance, peer-reviewed and emerging research, and first-party enterprise practices.",
"evidence_policy": "Evidence classes, source intent, scope, limitations, and company-practice boundaries should remain explicit."
},
"counts": {
"principles": 12,
"domains": 13,
"genres": 28,
"findings": 71,
"playbooks": 18,
"recommendations": 31,
"references": 82
},
"object_types": [
"source",
"annotation",
"claim",
"evidence",
"warrant",
"assumption",
"concept",
"interpretation",
"recommendation",
"decision",
"counterargument",
"limitation",
"procedure",
"metric",
"persona",
"situation",
"impact-contract",
"challenge",
"output-manifest",
"provenance-activity"
]
}