Content Ownership Model
This page defines where each type of information belongs so Papr docs stay clear, deduplicated, and easy for humans and AI coding agents to parse.
Ownership Rules
Overview Owns: Why and When
Overview pages answer:
- what capability exists,
- when to use it,
- how to choose a path.
Overview should not contain long implementation walkthroughs.
Quickstart Owns: First Working Integration
Quickstarts must optimize for time-to-first-success:
- one path,
- minimal configuration,
- copy/paste snippets.
Quickstarts should avoid deep conceptual digressions.
Guides Own: One Capability at a Time
Guides are task-focused references for production usage:
- one core capability per page,
- required inputs,
- recommended settings,
- common errors.
Integrations Own: Stack-Specific Implementation
Integrations pages are for framework and platform wiring:
- required setup for a stack,
- minimal integration path,
- production settings,
- validation checklist.
Integrations should link to examples for runnable snippets.
Tutorials Own: End-to-End Use Cases
Tutorials show complete systems:
- scenario,
- architecture,
- implementation,
- validation.
Tutorials should link back to the guide for each capability rather than redefine it.
API Reference Owns: Contract Only
API reference should remain authoritative for:
- endpoint paths,
- request/response schema,
- parameter constraints.
Reference should not become narrative docs.
Single-Source Concept Ownership
Assign one "home page" per concept:
- Predictive memory ->
overview/predictive-memory.md - Unified graph ->
overview/unified-graph.md - Structured data import ->
overview/structured-data.md - Capability mapping ->
overview/capability-matrix.md - Integration routes ->
overview/golden-paths.md
All other pages link to the concept home page.
Cross-Linking Contract
Every new guide and tutorial should include:
- When to use this
- Required endpoints
- Related quickstart
- Related API reference
- Next step
This keeps navigation deterministic for both people and coding agents.
Anti-Patterns to Avoid
- Repeating full conceptual explanations in multiple sections.
- Mixing deprecated and current fields without clear migration notes.
- Creating framework pages that diverge in core recommendations.
- Hiding critical defaults (for example, agentic graph settings).
- Using competitor callouts instead of outcome-focused guidance.