RISE Specification: Ceremony Protocol Integration#

Desired Outcome#

Every concept access and modification in the DSL server is governed by Indigenous data sovereignty principles (OCAP) and ceremony-aware workflows. The server does not merely store knowledge — it stewards knowledge with the same accountability that ceremony demands.

Current Reality#

• Concepts are stored as flat YAML entries without access governance
• Modifications are file edits without consent or review protocols
• No distinction between concepts that are openly shareable and those requiring ceremony
• The ecosystem has formalized OCAP flags and ceremony protocols in medicine-wheel packages, but these are not applied to concept management

Structural Tension#

Between a concept registry that treats all knowledge as uniformly accessible and one that honors the varying levels of sacredness, ownership, and access protocol that Indigenous knowledge systems require.

---

Key Features#

1. OCAP Governance on Every Concept#

Each concept carries OCAP flags that determine access behavior:

```yaml

Example: concept with restricted access#

two_eyed_seeing: id: two-eyed-seeing ocap: ownership: "Mi'kmaq knowledge tradition" control: "Knowledge keepers and community stewards" access: "open" # open | restricted | ceremony_required possession: "shared" # shared | community_held | elder_held ```

Access levels:

• open — Concept definition and context freely available to any query
• restricted — Definition available; Indigenous knowledge connections require steward approval or specific agent authorization
• ceremony_required — Full concept context only available within a ceremony-initiated session; otherwise returns a respectful notice that ceremony is needed

2. OCAP Enforcement in Query Engine#

```python class OcapGate: """Enforces OCAP flags on every concept access"""

def check_access(self, concept: ConceptNode, requester: RequesterContext) -> AccessResult:
    if concept.ocap.access == "open":
        return AccessResult.GRANTED
    
    if concept.ocap.access == "restricted":
        if requester.is_authorized_steward:
            return AccessResult.GRANTED
        return AccessResult.PARTIAL  # Return definition only, not Indigenous connections
    
    if concept.ocap.access == "ceremony_required":
        if requester.ceremony_session_active:
            return AccessResult.GRANTED
        return AccessResult.CEREMONY_NEEDED  # Return notice, not content

```

3. Four Directions Metadata Enrichment#

Every concept carries a primary directional alignment:

Every query response includes the directional question as a reflective prompt.

4. Ceremony Change Protocol#

When the concept registry is modified:

```python class CeremonyChangeProtocol: """Governs concept registry modifications as ceremonial acts"""

SIGNIFICANCE_THRESHOLDS = {
    "trivial": ["typo fix", "example added"],
    "minor": ["usage context expanded", "relationship added"],
    "significant": ["definition changed", "Indigenous connection modified"],
    "major": ["concept added", "concept deprecated", "OCAP flags changed"]
}

def evaluate_change(self, diff: ConceptDiff) -> CeremonyRequirement:
    significance = self.assess_significance(diff)
    
    if significance in ["trivial", "minor"]:
        return CeremonyRequirement(
            level="acknowledge",
            action="Log change in Ceremony Change Journal"
        )
    
    if significance == "significant":
        return CeremonyRequirement(
            level="witness",
            action="Change requires at least one steward to witness and approve",
            steward_approval_required=True
        )
    
    if significance == "major":
        return CeremonyRequirement(
            level="ceremony",
            action="Change requires ceremonial session: intention, reflection, consent",
            ceremony_session_required=True,
            four_directions_review=True  # Review from each directional perspective
        )

```

5. Ceremony Change Journal#

All concept modifications are recorded:

```python class CeremonyChangeEntry(BaseModel): timestamp: datetime change_type: str # "added" | "modified" | "deprecated" concept_id: str ceremony_level: str # "acknowledge" | "witness" | "ceremony" changed_by: str # Who made the change witnessed_by: list[str] # Who witnessed/approved ceremony_id: Optional[str] # If a ceremony session was held direction_reviews: dict # Which directions reviewed this change reflection: Optional[str] # Brief reflection on why this change matters reciprocity_note: Optional[str] # How this change gives back ```

6. Directional Balance Monitoring#

The server tracks whether concept usage and evolution maintain directional balance:

```python class DirectionalBalanceMonitor: """Tracks whether concept activity is balanced across Four Directions"""

def assess_balance(self, period: str = "week") -> DirectionalBalance:
    usage = self.wisdom_ledger.get_usage_by_direction(period)
    return DirectionalBalance(
        east=usage.get("east", 0),
        south=usage.get("south", 0),
        west=usage.get("west", 0),
        north=usage.get("north", 0),
        is_balanced=self._check_balance(usage),
        recommendation=self._suggest_rebalancing(usage)
    )

```

If one direction is significantly over- or under-represented, the monitor suggests exploration of neglected directions.

Integration with Existing Ceremony Protocol Package#

The medicine-wheel-ceremony-protocol npm package defines ceremony types and workflows. The DSL server aligns with these:

Success Metrics#

• Every concept has valid OCAP flags (4/4 fields populated)
• restricted concepts return partial responses to unauthorized requesters
• ceremony_required concepts never leak full content outside ceremony sessions
• All concept modifications are logged in the Ceremony Change Journal
• Significant changes (definition, Indigenous connections) trigger steward review
• Directional balance is assessed weekly and recommendations surfaced
• Four Directions reflective prompts are included in every concept response

Dependencies#

• Concept Registry (from rispecs.md)
• OcapFlags type alignment (from rispecs-ontology-bridge.md)
• Wisdom Ledger (from rispecs-wisdom-ledger.md)
• medicine-wheel-ceremony-protocol type definitions as reference