Documentation

Getting Started

Get up and running with the Cascade Protocol in your language of choice.

Tools & SDKs

Install the tools you need to build with the Cascade Protocol.

npm install -g @the-cascade-protocol/cli

npm install @the-cascade-protocol/sdk

pip install cascade-protocol

npm install -g @the-cascade-protocol/agent

Security & Compliance

The Cascade Protocol is designed with security and regulatory compliance at its core. Learn about encryption, access control, agent consent, and HIPAA-ready architecture.

Protocol Comparison

See how the Cascade Protocol compares to other health data standards and approaches: FHIR R4, Apple HealthKit, OpenEHR, and ad-hoc JSON. Includes a side-by-side comparison table, code examples for the same data in each format, and an honest assessment of Cascade's strengths and weaknesses.

Case Studies

Real-world examples of the Cascade Protocol in production.

Specification

Formal specifications governing the Cascade Protocol data format, versioning, and pod structure.

Agent Integration

Build AI agents that can securely access and process Cascade Protocol health data with explicit user consent.

Three-Layer Ontology Architecture

The Cascade Protocol organizes health data into three layers, each serving a distinct purpose:

Semantic Vocabularies

The Cascade Protocol uses modular RDF vocabularies built on W3C standards. Each vocabulary can be versioned independently while maintaining interoperability.

Ontology Explorer

Visualize the relationships between all Cascade Protocol vocabularies interactively. Explore the three-layer architecture, class hierarchies, and cross-vocabulary links as graphs and sortable tables.

Interactive Guide

Explore the Cascade Protocol documentation interactively. Ask questions, get explanations, and learn about the vocabularies through conversation.

Powered by Google NotebookLM. Requires a Google account to access.

Quick Start

Here's a minimal example showing how the vocabularies work together:

@prefix cascade: <https://ns.cascadeprotocol.org/core/v1#> .
@prefix pots: <https://ns.cascadeprotocol.org/pots/v1#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<#pots-check-abc123> a pots:POTSCheckResult ;
    # Core vocabulary properties
    cascade:schemaVersion "1.2" ;
    cascade:dataProvenance cascade:ConsumerGenerated ;

    # POTS-specific properties
    pots:date "2025-12-05T14:30:00Z"^^xsd:dateTime ;
    pots:protocol "nasaLean" ;
    pots:potsThresholdMet "true"^^xsd:boolean ;

    # Provenance tracking
    prov:wasAttributedTo <https://id.cascadeprotocol.org/users/abc123> .

SDKs

npm install @the-cascade-protocol/sdk

pip install cascade-protocol

Guiding Principles

1. Established vocabularies first. Reference FHIR, LOINC, SNOMED CT, PROV-O, and other established standards before creating Cascade-specific terms. We only invent vocabulary when no standard exists.
2. Three-layer ontology architecture. Every data type follows the Layer 1 (standards) → Layer 2 (domain) → Layer 3 (patient) pattern described above.
3. SNOMED CT and LOINC mappings required. All clinical and wellness metrics must map to standard codes unless no code exists — in which case the gap is documented explicitly.
4. Clear vocabulary separation. clinical: for EHR-derived facts, health: for consumer device data, pots: for POTS screening protocol (Layer 2), coverage: for insurance/benefits (Layer 2), checkup: for patient-facing summaries, core: for cross-cutting primitives, and domain prefixes for specialized protocols.
5. Privacy-first, local-first. Data stored in Solid Pods with AES-256-GCM encryption at rest. No external API calls for core functionality.
6. Provenance tracking. W3C PROV-O metadata on all data — distinguishing consumer-generated (device/user) from clinical-generated (EHR/provider) sources.

Ontology Objectives

1. Interoperability: Any domain property should be traceable to established standard codes (SNOMED CT, LOINC, FHIR) so that Cascade data can round-trip with clinical systems.
2. Completeness: Every data type serialized to Turtle has a corresponding vocabulary definition. No undefined terms.
3. Consistency: All vocabularies follow the same structural patterns — OWL ontology headers, version info, changelogs, and SHACL shapes where appropriate.
4. Discoverability: Every vocabulary has both a machine-readable .ttl file and a human-readable documentation page, linked from this index.
5. Accuracy: Version numbers in documentation match the actual .ttl file versions. Changelogs reflect all changes.

Resources

• W3C RDF Specification
• W3C OWL Web Ontology Language
• W3C PROV-O Provenance Ontology
• Solid Project
• HL7 FHIR

Technical Blog

Deep dives into the technology and design decisions behind the Cascade Protocol.

View all posts →