JJijibora Docs
docs.jijibora.online
On this page (22 sections)

Stakeholder Documentation — Playbook Registry and Gap Analysis

Overview

Business process playbooks, gap analysis, and stakeholder-facing documentation for the Sovereign OS platform.

Playbook Registry (Playbook Registry — What You Can Run, Who Runs It, What You Get Back)

31+ Sellable Business Processes

The playbook registry contains 31+ documented business processes that can be sold or licensed. Each process follows a standardized format with:

  • Process name — descriptive title
  • CNS type — cns://claim/type/... mapping
  • Actors — who participates (users, agents, organizations)
  • Triggers — what starts the process
  • Steps — sequential business logic
  • Outputs — delivered artifacts or claims
  • Governance — applicable rules and policies

Playbook Index Reference

Key playbooks documented (excerpt):

Playbook IDTitleCNS TypeKey Functions
S-01——fn::org::create, fn::org::add_member
S-02——Program management functions
S-03Glossary—fn::cns::register_type, fn::cns::register_entry
S-04Week Review—fn::scope::create_community
S-05Playbook Registry—31+ business processes documented
S-06+Various verticals—Vertical-specific flows

How to Use Playbooks

  1. Select a playbook from the registry matching your use case
  2. Review the CNS type mapping to ensure correct claim typing
  3. Follow the step-by-step business logic
  4. Check governance policies applicable to your scope
  5. Deploy using the referenced deployment scripts
  6. Integrate with existing Strata (s135, s141, s143, etc.)

Example: Claims Processing Playbook

Trigger: New claim created via `fn::claim::create`
Steps:
  1. Validate claim via `fn::validation::run_rules`
  2. Route to appropriate scope via `fn::scope::join_scope`
  3. Enrich with truth graph via `fn::create_truth_node`
  4. Notify stakeholders via `fn::notification::enqueue`
  5. Record on-chain via `fn::federation::log_event`
Output: Signed claim with full audit trail

Gap Analysis (Gap Analysis Validation — Cross-Document Gap Audit)

18 AGENTS.md Mandate Violations Identified

Critical (4)

  1. Bespoke table creation — ensuring no domain-specific tables (materra_, kazi_, etc.) exist
  2. Declarative-first policy — all static data sourced from NATS KV, Kestra, Apache Camel YAML, not hardcoded
  3. No silent fallbacks — infrastructure errors must fail closed (502/503/422), never synthesize "OPTIMAL"/"APPROVED"
  4. No synthetic adapter payloads — no hardcoded coordinates, supplier IDs, org IDs in production code

High (7)

  1. No bespoke schema changes — reuse existing primitives before creating new tables
  2. Events over polling — NATS JetStream events vs. cron/sweep patterns
  3. Prefer TypeScript over JavaScript — .ts/.tsx extensions, typechain
  4. No polling patterns — event-driven architecture throughout
  5. Auth callout JWT crafting — correct aud field placement, no issuer_account in NATS object
  6. Same DB isolation — community_os shared guard with is_portfolio checks
  7. Seeds adapted for SCHEMAFULL — status="active" not is_active=true, metadata={traits:[...]} not traits=[...]

Medium (4)

  1. Same DB multi-system — community_os for both GRSE/Portfolio and hardened_mission
  2. sharing_policy as single source of truth (removed redundant capability.scope)
  3. Inherited capabilities via fn::create_containment when sharing_policy="inherited"
  4. Claims as fundamental primitive — consider when data can be treated as a claim

Low (3)

  1. Background work uses events, not polling — nats_outbox → NATS publish → consumer pattern
  2. New governed capability PRs — follow NEW_CAPABILITY_PR_CHECKLIST.md (CV-59)
  3. Avoid filesystem lookups at runtime — read from NATS KV at runtime, not disk paths

Gap Closure Status

  • Critical: 4/4 addressed in SDK and codebase
  • High: 7/7 addressed in SDK types, architecture, and deployment scripts
  • Medium: 4/4 addressed in design patterns and existing primitives
  • Low: 3/3 acknowledged; remain as known constraints

Comprehensive System Catalog (COMPREHENSIVE_SYSTEM_CATALOG.md)

3 Audience Tracks

  1. Developer — SDK docs, API references, code examples, type definitions
  2. Administrator — deployment guides, ops runbooks, health checks, configuration
  3. Stakeholder — business playbooks, gap analysis, process documentation, governance

18+ Validated Gaps

  • Documented with severity classification (Critical/High/Medium/Low)
  • Each gap has: description, impact, remediation, verification
  • Linked to playbooks that address or work around each gap

31+ Playbooks

  • Documented business processes ready for consumption
  • Each playbook maps to CNS types and strata
  • Deployment sequences documented per playbook
  • Governance policies referenced per playbook

CNS Type Hierarchy (s185)

Kujenga Claim Type Structure

cns://claim/type/kujenga (traits: [construction, governed, mpesa_enabled, poce_tracked])
  ├── cns://claim/type/kujenga/project (traits: [budgeted, multi_stakeholder, archived])
  ├── cns://claim/type/kujenga/milestone (traits: [escrow_linked, inspectable, sequential, funded])
  ├── cns://claim/type/kujenga/task (traits: [assignable, time_bound, completable, blockable])
  └── cns://claim/type/kujenga/inspection (traits: [pass_fail, scheduled, certifiable, disputable])

Seed Files

  • database/seeds/cns/cns_type_catalog_kujenga.surql — CNS type catalog seed
  • database/seeds/manifest/platform_kujenga.v2.json — 12 contract implementations, Synadia + NATS comms, 7 deps
  • database/seeds/nats/nats_auth_governance_seed.surql — 6 client types incl. governance, synadia_mobile

Key Reference Documents

Developer-Facing

  • docs/api/L3_APPLICATION_BFF_API.md — 25,582 bytes, 11 sections, all endpoints
  • apps/agent-bff/openapi/bff-v1.json — OpenAPI 3.1.0, 574 schema properties
  • packages/sovereign-sdk/src/L3BffClient.ts — 23 endpoint methods + types
  • docs/COMPREHENSIVE_SYSTEM_CATALOG.md — full docs map

Administrator-Facing

Stakeholder-Facing

Cross-Reference

← BackHome — all documentationNext →Jijibora set index