CAB Research Interface

Purpose

When Recursive Systems Labs research informs applied software systems (e.g., clinical platforms, organizational tools, future SDKs), a governance layer is required.

The Clinical Advisory Board (CAB) serves as that layer.

This document describes the CAB's role, authority, and relationship to RSL research.

What the CAB Is

The Clinical Advisory Board is a deliberative body that reviews proposed capabilities, features, and integrations before they enter production systems.

The CAB is not:

• A product roadmap accelerator
• A velocity optimization mechanism
• A compliance checkbox
• A rubber stamp for pre-decided features

The CAB is:

• A structural constraint on scope expansion
• A forum for ethical and operational review
• An authority that can say "no" or "not yet"
• A mechanism to preserve non-extractive design

CAB Authority

The CAB has veto authority over:

• New feature development
• Schema changes that expand data collection
• Integration with third-party systems
• Changes to audit, telemetry, or logging
• Migration from one phase to another (e.g., EMA 1.0 → 2.0)

No capability enters production without CAB sign-off.

This authority is institutional, not ceremonial.

When CAB Review Is Required

CAB review is mandatory for:

1. New Capabilities

• Any feature that collects, stores, or processes user data
• Features that change user workflows or obligations
• Features that introduce automation or decision support

2. Data Architecture Changes

• New database tables or columns
• Changes to PHI classification
• Modifications to encryption or access controls
• Audit log schema changes

3. Third-Party Integration

• Authentication providers
• Cloud storage or compute services
• Analytics or monitoring tools
• Communication platforms (email, SMS, telehealth)

4. Phase Transitions

• Moving from pilot to production
• Expanding from one user population to another
• Adding new organizational sites or partners

5. Incident Response Changes

• Post-incident architectural modifications
• Changes to rollback or recovery procedures
• Updates to security protocols

CAB Review Process

1. Proposal Submission

Developer or architect submits:

• Feature description and user impact
• Schema changes (if any)
• Data flow diagrams
• PHI handling assessment
• Surveillance drift analysis
• Rollback strategy

2. CAB Deliberation

CAB reviews against:

• Non-Harm Commitment alignment
• Research Use Boundary compliance
• Dual-Use Risk assessment
• Non-extractive design principles
• Operational readiness

3. CAB Decision

Possible outcomes:

• Approved: Proceed with implementation
• Approved with conditions: Implement with specified constraints
• Deferred: Requires additional information or design iteration
• Rejected: Does not align with RSL principles, not pursued

4. Documentation

All CAB decisions are documented with:

• Rationale for approval or rejection
• Conditions or constraints imposed
• Date and participants
• Reference to relevant governance documents

CAB Principles

1. Restraint Over Velocity

• Slower, safer development is preferred
• "Not yet" is a legitimate answer
• Capability expansion requires justification, not just permission

2. Skepticism of Optimization

• Efficiency gains that reduce human judgment are suspect
• Automation that removes user agency is rejected
• "Streamlining" that normalizes surveillance is prohibited

3. Transparency Over Convenience

• Users must understand what the system does
• Hidden data collection is not acceptable
• Defaults favor user control, not system convenience

4. Reversibility

• Features must be removable without data loss
• Rollback procedures are required before deployment
• No "one-way door" architectural decisions

Relationship to Research

RSL research (e.g., ODTBT, recursive systems modeling) provides conceptual frameworks.

The CAB ensures that translation from research to software:

• Preserves diagnostic intent (does not become prescriptive)
• Maintains human agency (does not automate judgment)
• Respects boundaries (does not enable prohibited uses)
• Operates transparently (does not obscure function)

Research informs; governance constrains; humans decide.

Public Accountability

CAB decisions that affect user-facing systems are documented publicly (with operational details redacted).

This accountability serves:

• Users (understand what they're consenting to)
• Researchers (see how frameworks are applied)
• Partners (evaluate alignment with their values)
• The broader community (assess RSL's adherence to commitments)

Closing

The CAB exists because capability alone does not justify deployment.

Technical sophistication does not equal ethical clearance.

Speed does not equal responsibility.

The CAB is the structural mechanism that enforces what RSL's values declare.