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