Skip to content

Message-passing module architecture: typed channels between toolchain components (Basilisk/F' pattern) #97

@avrabe

Description

@avrabe

Context

Basilisk (ESA astrodynamics framework) modules communicate exclusively through typed messages with zero compile-time dependencies. NASA F' auto-generates communication code from component specs. Both achieve independent compilation and easy module replacement.

Problem

PulseEngine's 16 workspaces have varying levels of coupling. Inter-crate communication uses direct struct imports, creating compile-time dependencies. The MCP framework provides a natural inter-process communication layer but isn't used for internal toolchain coordination.

Proposal

Use MCP as the typed message-passing layer between toolchain components:

Define WIT interfaces for toolchain communication

interface optimizer {
    record optimization-request {
        module-bytes: list<u8>,
        config: optimization-config,
    }
    record optimization-result {
        optimized-bytes: list<u8>,
        stats: optimization-stats,
        verification: verification-evidence,
    }
    optimize: func(req: optimization-request) -> result<optimization-result, error>;
}

Benefits

  1. Independent compilation: Each crate depends on WIT types, not other crates' Rust types
  2. Replaceable components: Swap Loom for an alternative optimizer without changing Synth
  3. Remote execution: Naturally supports distributed builds (optimizer on a different machine)
  4. Self-documenting: WIT interfaces are the single source of truth for inter-component contracts
  5. Dogfooding: PulseEngine's own toolchain uses the Component Model it builds for

Implementation path

  1. Define WIT interfaces for Loom↔Synth, Meld↔Kiln, Sigil↔build-pipeline boundaries
  2. Use MCP for process-level communication during builds
  3. Optionally compile toolchain components as WASM components themselves (full dogfooding)

References

Priority

Medium — improves modularity and build times across the ecosystem.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions