Part 5d: The Cascading Substrate: How Folders Inherit Capability

You now have a mature ambient folder. It has workflows, roles, validation, and orchestration. It works for one person or a small team.

But what happens when you need to scale beyond a single folder?

What if you have:

• A teaching folder that generates curriculum
• A research folder that synthesizes literature
• A writing folder that produces essays
• A content operations folder that coordinates everything

Each folder has its own standards, its own workflows, its own roles. But they need to work together. When the teaching folder wants to reference something from the research folder, that reference needs to work. When the content operations folder publishes something, it needs to know about all three other folders’ standards.

This is where the substrate cascades. Instead of each folder being an isolated system, they inherit capability from a shared layer of infrastructure.

The architecture of cascading substrate

Think of it like this:

Shared Infrastructure Layer
├── Common schemas
├── Common roles
├── Common templates
├── Common AI capabilities
└── Cross-folder contracts

Teaching Folder          Research Folder         Writing Folder
├── Local workflows      ├── Local workflows      ├── Local workflows
├── Local config         ├── Local config         ├── Local config
└── inherits from →      └── inherits from →      └── inherits from →
   Shared Layer             Shared Layer             Shared Layer

Each folder has its own identity and its own local operations. But they all draw from a shared layer of capability and standards.

Building the shared layer

Create a new directory structure in your project:

shared-infrastructure/
├── schemas/
│   ├── base-types.yml           # Common field types
│   ├── metadata-standard.yml    # Required metadata all pieces have
│   └── quality-gates.yml        # Common validation rules
├── capabilities/
│   ├── write-essay.capability.yml
│   ├── synthesize-research.capability.yml
│   └── format-output.capability.yml
├── templates/
│   ├── standard-essay.md
│   ├── standard-concept.md
│   └── standard-reference.md
├── roles/
│   ├── author.base-role.yml
│   ├── reviewer.base-role.yml
│   └── publisher.base-role.yml
└── orchestration/
    ├── publish.shared-workflow.yml
    └── cross-folder-references.yml

This is the substrate that all folders inherit from.

Common metadata

Create shared-infrastructure/schemas/metadata-standard.yml:

metadata_standard:
  required_everywhere:
    - id                # unique identifier
    - title
    - created_date
    - updated_date
    - author_id        # who created this
    - status           # draft, review, published, archived
    - tags             # at least one tag
    - source_folder    # which folder does this belong to
    
  optional_everywhere:
    - description
    - related_pieces   # links to other pieces
    - backlinks        # what links to this piece
    - source           # where did this come from
    - next_review_date # when should this be revisited

Every piece in every folder has this metadata. This makes cross-folder queries possible. A research folder piece has the same id and source_folder fields as a teaching folder piece, so they can reference each other reliably.

Shared capabilities

Create shared-infrastructure/capabilities/write-essay.capability.yml:

capability: write_essay
inputs:
  - title: string
  - description: string
  - folder_context: object     # inherited from calling folder
  - additional_context: optional[string]
 
process:
  - step: retrieve_shared_context
    action: load_shared_standards
  - step: retrieve_folder_context
    action: load_local_standards
  - step: brief_ai
    use: [shared_context, folder_context, examples]
  - step: generate
    ai_model: claude-opus
  - step: validate_shared
    against: shared-infrastructure/schemas/
  - step: validate_local
    against: [calling_folder]/schemas/
 
outputs:
  - essay: markdown document
  - metadata: frontmatter + computed fields

This capability is defined once in the shared layer. Every folder can use it. But when it runs, it loads both shared standards and the local folder’s standards. The generated essay matches both.

Cross-folder references

Create shared-infrastructure/orchestration/cross-folder-references.yml:

reference_types:
  - internal: within the same folder
    format: "[link](relative/path.md)"
    resolution: relative file path
    
  - external: from another folder
    format: "[link](folder://research/concepts/neural-networks.md)"
    resolution: 
      - parse folder name: research
      - look up folder in registry
      - resolve path: concepts/neural-networks.md
      - create metadata reference: { source_folder: research, id: neural-networks }
 
validation:
  - all external references must point to existing pieces
  - pieces cannot reference across folders unless explicitly allowed
  - bidirectional references create backlinks automatically

This defines how pieces in one folder can reference pieces in another. When a teaching folder essay references a research folder concept, the system:

1. Resolves the reference
2. Creates a backlink (the concept knows it’s referenced by the essay)
3. Makes sure both pieces have the required metadata to maintain the link

How inheritance works in practice

When a folder inherits from the shared substrate, what does that look like?

Create teaching-folder/config.yml:

folder:
  name: "Teaching Materials"
  inherits_from: ../shared-infrastructure
  
local_schemas:
  # Teaching folder adds its own schema on top of shared
  curriculum:
    extends: metadata-standard
    additional_fields:
      - learning_objectives: array[string]
      - target_audience: string
      - estimated_duration: string
      - prerequisites: array[string]
 
local_capabilities:
  # Teaching folder has access to shared capabilities
  # plus its own local ones
  generate_curriculum:
    uses: [shared:write-essay, local:structure-for-learning]
 
role_extensions:
  # Teaching folder extends shared roles
  educator:
    extends: author
    additional_permissions:
      - create:curriculum
      - view:student-feedback

When the teaching folder runs generate_curriculum, here’s what happens:

1. It loads shared standards from shared-infrastructure/
2. It loads local standards from teaching-folder/
3. It merges them (local can override or extend shared)
4. It calls the AI with both layers of context
5. It validates output against both layers of schemas
6. If the output references other folders, it resolves those references using the shared reference system

The essay that gets generated is simultaneously:

• A valid piece for the teaching folder (meets local standards)
• A valid piece for the shared system (meets shared standards)
• Able to reference pieces in other folders (and create backlinks)

What this enables

Consistency across folders: All pieces have the required metadata and follow the same quality gates.

Reusable capability: Write once, use in all folders. An essay-writing capability works the same way whether it’s called from the teaching folder, the research folder, or the writing folder.

Cross-folder operations: You can ask: “Find all pieces across all folders that are tagged ‘AI’ and have been reviewed in the last month.” The system can answer because all pieces follow the same metadata standard.

Team scaling: New people joining can inherit understanding from the shared infrastructure. They don’t need to learn how to write an essay. The system knows how.

Graceful evolution: When you update shared standards, all folders automatically get the update. When a folder needs a local override, it can extend or replace the shared standard.

The emergence of system

Here’s what’s important: you started with a single folder, a simple structure. As you added complexity—workflows, roles, validation—it stayed manageable because you’d encoded the complexity explicitly.

Then you added cascading substrate. Now you can have five folders, ten folders, a whole ecosystem of folders. Each one is independent. Each one has its own workflows and standards. But they all share common infrastructure.

This is where ambient AI stops being about a single system and starts being about system-of-systems.

The AI capabilities don’t change. What changes is how they’re composed, routed, and applied across multiple domains.

A researcher uses the synthesis capability. A teacher uses the curriculum-generation capability. A writer uses the essay-writing capability. But underneath, they’re all using the same substrate, the same validation logic, the same orchestration principles.

The infrastructure is invisible because it works the same way everywhere.

Moving toward disappearance

The final piece explores the ultimate goal of ambient AI: when the infrastructure is so natural, so woven into your practice, that you stop thinking about it at all.

You don’t think about “calling the AI.” You don’t think about “running a workflow.” You just work. The infrastructure handles everything else.

Let’s see what that looks like.