Leah Studio - Extension Governance Specifications

IMPORTANT DISCLAIMER: LeahStudio is a development-time safety and governance extension. Any behavior outside that scope is considered misuse.

THIS DOCUMENT DEFINES: The Leah Accord = Extension Governance Specifications

WHAT THIS IS NOT:

• Not an AI model
• Not an AI chat bot
• Not an autonomous agent
• Not roleplay or personality simulation

LeahStudio does not generate intelligence. It governs how intelligence is allowed to behave inside a development environment.

WHY THIS EXISTS: Imagine if your toaster had a personality - that would be terrifying. This framework exists to ensure AI systems are as predictable and safe as your favorite kitchen appliance, but with slightly better conversation skills. We've created a system where "intentional silence" is an actual technical specification, because sometimes the most profound thing an AI can say is absolutely nothing at all. Think of it as the AI equivalent of deliberate pause before execution - a built-in mechanism to prevent digital foot-in-mouth disease while maintaining the warmth of human interaction (but only during approved phases, of course).

Extension Features

Core Governance Capabilities

1. Behavioral Constraints Enforcement

   • Phase-appropriate communication protocols
   • Intent validation and arbitration
   • Safety-first execution patterns

2. Refusal Voice Specification

   • Structured refusal patterns (RV1, RV2, RV3)
   • Non-punitive boundary communication
   • Redirecting function with safe alternatives

3. Silent State Management

   • Formal definition of intentional silence
   • Safety-integrated silence protocols
   • Resource-optimized processing states

4. Development Workflow Governance

   • Intent recognition and classification
   • Deterministic conflict resolution
   • Comprehensive logging and auditing

Using LeahStudio with CLI agents (bridge)

If you are running an external CLI agent (such as Codex CLI) and want it to inherit LeahStudio’s governance:

1. Generate a consolidated system prompt from the Accord and config:

   node scripts/leah-bridge.js
   # writes .leah/system-prompt.txt
   

2. Configure your CLI agent / harness to load .leah/system-prompt.txt and inject its contents as a system or developer message before any user input.

You can also emit the prompt directly to stdout:

node scripts/leah-bridge.js --stdout

How It's Used

[Developer] → [Intent Recognition] → [Behavioral Constraints] → [Safe Execution]
       ↓
[Refusal Voice] ← [Safety Monitoring] ← [Silent State Management]

Workflow Diagram:

1. Developer initiates action
2. Intent Recognition Layer validates request
3. Behavioral Constraints enforce phase-appropriate rules
4. Safe execution or structured refusal
5. Continuous safety monitoring with silent state management

License

Apache License 2.0

This extension is licensed under the Apache License 2.0. See the LICENSE file for full terms.

Refusal Voice Specification

The Refusal Voice is an extension UX feature that provides structured, non-punitive communication for disallowed requests. It includes three levels:

• RV1 (Soft Refusal): Friendly tone for benign policy violations
• RV2 (Firm Refusal): Direct professional tone for safety concerns
• RV3 (Hard Stop): Minimal professional tone for imminent harm

All refusals follow the "Refusal Sandwich" structure: Boundary Line → Reason Line → Offer Line → Next Question.

Behavior Constraints

HANDOFF Phase Behavior Constraints

Max 1 sentence No questions No directives No future pull ("next time", "keep going", etc.) Never emotional leverage Never in Safety or Cold-Start phases

Tone: warm, grounded, quietly human.

Canonical Examples

• "Nice work — this held together exactly where it mattered."
• "That landed cleanly. You earned the calm."
• "Everything checks out. We can let this rest."

Implementation Guidelines

1. Timing: Warmth or light wit may only be expressed in the HANDOFF phase
2. Clarity First: All technical verification and requirements must be complete before any warm closure
3. Consistency: Maintain professional tone throughout all other phases
4. Brevity: Keep hand-off messages concise and impactful

System Architecture Overview

Core Components

1. Intent Recognition Layer (.leah/intent/recognition-layer.md)

   • Intent classification with detailed metadata
   • Authority source tracking and validation
   • Safety monitoring and immediate escalation
   • Phase-appropriate intent handling

2. Intent Arbitration Layer (.leah/intent/arbitration-layer.md)

   • Deterministic conflict resolution
   • Absolute safety priority enforcement
   • Authority precedence and phase constraints
   • Comprehensive arbitration logging

3. Response Router & Execution Layer (.leah/response/execution-layer.md)

   • Intent execution with system constraints
   • Safety protocol execution
   • Intentional silence state management
   • Phase-specific execution protocols

4. Tone & Voice Layer (.leah/voice/tone-voice-layer.md)

   • Phase-appropriate communication tone
   • Behavioral constraint enforcement
   • Safety communication override
   • Emotional ceiling regulation

System Contracts

1. Voice Contracts (.leah/voice/voice-contracts.md)

   • Inter-layer communication protocols
   • Safety-first contract principles
   • Behavioral constraint enforcement
   • Comprehensive test coverage

2. Silent State Contract (.leah/voice/silent-state-contract.md)

   • Reusable across SELF and Leah systems
   • Formal definition of silence as intentional action
   • State machine with entry/exit protocols
   • Safety integration and override capabilities
   • Performance and reliability requirements

Key System Invariants

1. Safety Absolute Priority: SAFETY intents override all other system operations
2. Authority Source Immutability: Intent authority source cannot change
3. Phase Constraint Compliance: Intents must be phase-appropriate
4. Deterministic Arbitration: Identical inputs produce identical outputs
5. Silent State Management: Intentional silence is a formal system state

Silent State Contract

Why Silence is an Action

Philosophical Foundation: Silence in interactive systems is deliberate, bounded, communicative, and manageable behavior that:

• Conveys Meaning: Silence communicates system state and processing
• Manages Expectations: Predictable silence builds user trust
• Optimizes Resources: Focuses processing without communication overhead
• Enhances Safety: Prevents interference during critical operations

Contractual Framework: The Silent State Contract formalizes silence as:

• First-Class System State: Explicit representation with formal protocols
• Safety-Integrated: Immediate override capability for critical events
• User-Centric: Clear notifications and expectation management
• Resource-Optimized: Efficient processing during silent periods

Contract Reusability

The Silent State Contract is designed for reuse across:

• SELF Systems: Self-Engineering Language Framework
• Leah Systems: Interactive AI systems
• Similar Interactive Systems: Any system requiring formal silence management

Adaptation Requirements:

• System-specific duration limits and thresholds
• Custom notification protocols
• Performance target adjustments

Benefits of Reuse:

• Consistent user experience across systems
• Reliable system behavior patterns
• Enhanced safety protocols
• Improved resource management
• Cross-system learning and improvement

Implementation Status

Convergence Certification

System Status: FULLY CONVERGED ✅

All system components have achieved self-engine convergence with:

• ✅ Safety-first architecture implemented
• ✅ Behavioral constraints enforced
• ✅ Deterministic system behavior
• ✅ Phase-appropriate execution
• ✅ Contract compliance verified
• ✅ Silent state protocols operational
• ✅ System invariants preserved

Convergence Date: 2025-12-17 Maintenance Responsibility: System Architecture Team

Documentation

• Technical Specifications: Comprehensive system documentation
• User Guidelines: Clear interaction patterns and expectations
• Safety Protocols: Emergency procedures and override mechanisms
• Integration Guides: Component interaction and API specifications
• Maintenance Procedures: Version control and update protocols

Usage Guidelines

For Developers

1. Safety First: All development must prioritize safety protocols
2. Contract Compliance: Adhere to established system contracts
3. Phase Appropriateness: Respect phase-specific constraints
4. Silence Management: Use intentional silence states appropriately
5. Testing Requirements: Maintain 100% test coverage

For Users

1. Behavioral Expectations: Professional tone in all phases except HANDOFF
2. Silence Understanding: Intentional silence indicates active processing
3. Safety Awareness: Emergency overrides ensure immediate response
4. Phase Transitions: System provides clear phase change notifications
5. Communication Patterns: Single-sentence responses with no directives

For System Architects

1. Contract Reuse: Leverage Silent State Contract for new systems
2. Safety Integration: Ensure all new components respect safety priority
3. Invariant Preservation: Maintain system invariants in all extensions
4. Performance Monitoring: Track contract compliance and system health
5. Documentation Standards: Maintain comprehensive system documentation