# Knowledge Source Schema — Layer 3 Reusable Entity Type # KNO Schema Version: 0.1.0 # # A knowledge source is an addressable, citable unit of knowledge — a principle, # procedure, pattern, rule, or other extracted insight that can be referenced, # applied, and composed into collections. # # EXTENDS: document-schema.kno (which composes identity, history, quality) # USE CASES: # - Playbook entries (principles, procedures, patterns) # - Knowledge base articles # - Onboarding insights # - Best practices # - Documentation sections # # DESIGN PRINCIPLE: Reusable across contexts # A knowledge source is NOT playbook-specific. It's a general-purpose schema # for any unit of extractable, addressable knowledge. # ============================================================================= # SCHEMA DECLARATION # ============================================================================= $schema: kno@0.0.9 # ============================================================================= # IDENTITY # ============================================================================= id: 01KGRBF5C7W9A3V0515H9XGDEK slug: knowledge-source-schema type: spec version: 0.1.0 # ============================================================================= # STANDARD TIER # ============================================================================= title: "Knowledge Source Schema" purpose: | Define the schema for knowledge sources — addressable, citable units of knowledge that can be referenced, applied, and composed into containers. **What is a Knowledge Source?** A knowledge source is an atomic piece of extractable knowledge with: - A specific `subtype` (principle, procedure, pattern, rule, etc.) - A `domain` categorization - Addressability via XRI (can be `#entries/slug` within a container) - Applicability context (when/where it applies) **Subtypes:** | Subtype | Description | Example | |---------|-------------|---------| | `principle` | Foundational belief/approach | "Agent-first design" | | `procedure` | Step-by-step workflow | "Task creation workflow" | | `pattern` | Proven solution with context | "Repository structure pattern" | | `rule` | Hard constraint | "All PRs require review" | | `anti-pattern` | What to avoid | "Monolithic instruction files" | | `template` | Reusable structure | "Epic template" | | `reference` | Quick lookup information | "Git commit conventions" | | `definition` | Term/concept definition | "What is a Playbook?" | | `article` | Long-form content | "Getting Started Guide" | | `insight` | Extracted observation | "High test coverage correlates with..." | | `checklist` | Verification/completion list | "PR Review Checklist" | **Usage Contexts:** - **Playbook `_contains.entries`** — Methodology knowledge - **Knowledge Base `_contains.articles`** — Wiki content - **Onboarding `_contains.insights`** — Learning material - **Standalone** — Individual best practice documents **Layer 3 Position**: Knowledge Source extends document (Layer 2), which composes identity, history, and quality (Layer 1). # ============================================================================= # RICH TIER — Taxonomy # ============================================================================= provenance: origin: id: 01KGRBF5C7W9A3V0515H9XGDEK timestamp: "2026-02-05T00:00:00Z" tool: manual taxonomy: topics: - knowledge-management - methodology - documentation - playbooks - best-practices keywords: - knowledge-source - principle - procedure - pattern - rule - template - insight - checklist # ============================================================================= # RICH TIER — Relationships # ============================================================================= relationships: extends: - xri: "kno://specs/document-schema" reason: "Layer 2 base type for all documents" depends_on: - xri: "kno://specs/kno-spec" reason: "Defines kno@0.0.9 schema structure" composes: # Inherited through document-schema.kno: - xri: "kno://specs/identity-schema" reason: "id, slug, canonical_id" - xri: "kno://specs/history-schema" reason: "_history, changelog" - xri: "kno://specs/quality-schema" reason: "quality, validation" enables: # Contained by these schemas: - xri: "kno://specs/playbook-schema" reason: "Playbooks contain knowledge sources as entries" - xri: "kno://specs/knowledge-base-schema" reason: "Knowledge bases contain knowledge sources as articles" related_to: - xri: "kno://specs/definition-schema" reason: "Definition is a specialized knowledge source subtype" - xri: "kno://specs/role-schema" reason: "Roles complement knowledge sources in playbooks" quality: completeness: 0.75 last_reviewed: "2026-02-05" review_status: draft # ============================================================================= # HISTORY # ============================================================================= _history: version: 1 created: "2026-02-05T00:00:00Z" created_by: "pspace-core-team" modified: "2026-02-05T00:00:00Z" modified_by: "claude" # ============================================================================= # SPECIFICATION # ============================================================================= spec: status: Draft changelog: - version: "0.1.0" date: "2026-02-05" changes: - "Initial creation for Issue #81 (Playbook Container Architecture)" - "Designed as general-purpose schema, not playbook-specific" - "Supports containment in any KAML container via _contains" schema: type: object required: - id - subtype - title - content properties: # ----------------------------------------------------------------------- # BASIC TIER # ----------------------------------------------------------------------- $schema: type: string const: "knowledge-source@0.1.0" description: "Schema declaration" id: type: string description: | Unique identifier for this knowledge source. Convention: ks_{ulid} for standalone, or shortened for contained. examples: - "ks_01HXYZ123" - "explicit-over-implicit" # ----------------------------------------------------------------------- # STANDARD TIER # ----------------------------------------------------------------------- subtype: type: string enum: - principle - procedure - pattern - rule - anti-pattern - template - reference - definition - article - insight description: "What kind of knowledge this represents" title: type: string description: "Human-readable title" examples: - "Explicit Over Implicit" - "Task Creation Workflow" domain: type: string description: "Domain categorization path" examples: - "methodology.project_management" - "technical.architecture" - "culture.philosophy" content: type: string description: "Markdown content — the actual knowledge" # ----------------------------------------------------------------------- # RICH TIER # ----------------------------------------------------------------------- priority: type: string enum: - P0 - P1 - P2 description: "Importance/urgency (P0 = critical, P2 = nice-to-have)" applicability: type: object description: "When and where this knowledge applies" properties: contexts: type: array items: type: string description: "Situations where this applies" triggers: type: array items: type: string description: "Events that invoke this knowledge" prerequisites: type: array items: type: string description: "What must be true before applying" tags: type: array items: type: string description: "Searchable tags" related: type: array items: type: string description: "XRIs or IDs of related knowledge sources" source_file: type: string description: "Original file path (for extracted knowledge)" # ----------------------------------------------------------------------- # DIMENSIONS (for playbook entries) # ----------------------------------------------------------------------- dimensions: type: array items: type: string description: "Which analytical dimensions this covers" examples: - ["philosophy", "culture"] - ["process", "technical"] # ============================================================================= # EXAMPLES # ============================================================================= examples: - title: "Principle in a Playbook" description: "A principle entry contained in a playbook's _contains.entries" content: | $schema: knowledge-source@0.1.0 id: explicit-over-implicit subtype: principle title: "Explicit Over Implicit" domain: methodology.philosophy priority: P0 dimensions: - philosophy - culture content: | ## Statement All decisions, assumptions, and boundaries must be explicitly documented. Never assume shared understanding exists. ## Rationale Implicit knowledge creates confusion, especially in async/distributed work. What seems obvious to one person may be invisible to another. ## Application - Document all decisions in GitHub Issues or ADRs - Make agent instructions explicit, not assumed - State assumptions in code comments tags: - documentation - communication - clarity related: - bounded-autonomy - documentation-first - title: "Procedure in a Playbook" description: "A step-by-step workflow" content: | $schema: knowledge-source@0.1.0 id: task-creation-workflow subtype: procedure title: "Task Creation Workflow" domain: methodology.project_management priority: P1 content: | ## Overview How to create and structure tasks in the Possibility system. ## Steps 1. **Identify the need** — What problem are we solving? 2. **Check existing issues** — Avoid duplicates 3. **Create GitHub Issue** — Use appropriate template 4. **Add to Project** — Link to milestone if applicable 5. **Assign** — Tag relevant agent or human applicability: triggers: - "New feature request" - "Bug discovered" - "Technical debt identified" prerequisites: - "Access to GitHub repository" - "Understanding of project structure"