Skip to content

MacFall7/m87-governed-loop

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

M87 Governed Execution Loop — BPMN 2.0

ci

A production process model of the M87 Cognitive Execution Substrate, shipped as both a governance reference model and a deployable Camunda 8 / Zeebe process, backed by a pure fail-closed decision core proven by unit tests in Python and Java.

The core invariant — Proposal ≠ Execution — is enforced structurally: no agent reaches a runtime tool without passing two governance gateways, and no run is "complete" without a verifiable artifact. One success path; four fail-closed exits.

flowchart LR
    subgraph P[Proposer]
        Start([Task Intake]) --> Propose[ActionProposal<br/>+ reasoning trace]
    end
    subgraph G[Governance]
        Validate[Validate vs policy] --> GwC{constraints_ok?}
        GwM{tool_in_manifest?}
        Contract[ExecutionContract]
        Verify[Verify artifact] --> GwV{artifact_verified?}
    end
    subgraph R[Runner]
        Execute[Execute in budget] --> GwB{budget_exceeded?}
        Artifact[Artifact + Receipt hash]
    end
    subgraph M[Memory]
        Memory[Route + index] --> Done([Complete])
        Failed([Halted])
    end
    Propose --> Validate
    GwC -- "default" --> Halt([Halt & Escalate])
    GwC -- "= true" --> GwM
    GwM -- "default" --> RejM([Reject: manifest])
    GwM -- "= true" --> Contract --> Execute
    GwB -- "default" --> FR[Failure receipt] --> Failed
    GwB -- "= false" --> Artifact --> Verify
    GwV -- "default" --> RejV([Reject: verify])
    GwV -- "= true" --> Memory
    classDef halt fill:#3a1212,stroke:#c0392b,color:#fff;
    class Halt,RejM,RejV,Failed halt;
Loading

Two BPMN files, one set of node IDs

File isExecutable Purpose
reference/m87-governed-loop.bpmn false The spec / diagram. Opens in bpmn.io or Camunda Modeler.
executable/m87-governed-loop.bpmn true Camunda 8 / Zeebe. Service tasks carry zeebe:taskDefinition; gateways carry FEEL conditions.

Node IDs are identical across both, so the invariant mapping and the diagram interchange stay valid for either file.

Fail-closed is structural, not convention

In the executable model every gateway's default flow routes to a refusing exit. The permissive branch requires an explicit FEEL condition, so a missing or ambiguous variable always fails closed — at the engine level, not just in code.

Gateway Permissive branch (FEEL) default
Gw_Constraints =constraints_ok = true End_Halt
Gw_Manifest =tool_in_manifest = true End_RejManifest
Gw_Budget =budget_exceeded = false FailReceipt → End_Failed
Gw_Verify =artifact_verified = true End_RejVerify

The decision core (single source of truth)

The four gateway variables are computed once, by pure deterministic functions, and reused by the engine workers. A gate is a function; a gateway is the same function; the function is unit-testable without a running cluster.

Variable contract (set by the validate, execute, verify-artifact workers):

constraints_ok: bool      # Gw_Constraints   (validate)
tool_in_manifest: bool    # Gw_Manifest      (validate)
budget_exceeded: bool     # Gw_Budget        (execute)   — missing telemetry => true
artifact_verified: bool   # Gw_Verify        (verify-artifact)
  • Pythonworkers/python/governed_loop/ (gates.py is the core; workers.py wires pyzeebe).
  • Javaworkers/java/src/main/java/net/m87studio/governedloop/ (Gates.java mirrors it; Workers.java is the Camunda SDK glue).

Test story

The tests are invariant proofs, not smoke checks: each asserts that a specific malformed, ambiguous, or over-budget input reaches the correct fail-closed terminal, and that COMPLETE is reachable only through verification. One suite (test_bpmn_equivalence.py) parses the actual executable/ model and asserts its gateway routing reaches the same terminal decide() predicts for every terminal class — so "a gateway is the same function" is proven, not asserted. Receipts hash structured artifacts via canonical JSON, identical across Python and Java (a cross-language parity test pins this).

# Python  (44 tests: invariant proofs + BPMN<->code equivalence + cross-language hash parity)
cd workers/python && pip install -e ".[dev]" && python -m pytest tests/ -q

# Java    (11 tests, mirroring the Python suite)
cd workers/java && mvn test

CI (.github/workflows/ci.yml) runs three jobs on every push: xmllint on both BPMN files plus a fail-closed structure assertion, the Python suite, and the Java suite.

Deploy to Camunda 8

# Self-Managed (zbctl) or Web Modeler upload
zbctl deploy resource executable/m87-governed-loop.bpmn

# Run the workers (Python)
cd workers/python && pip install -e ".[zeebe]" && python -m governed_loop.workers

The workers register handlers for all eight job types: propose, validate, issue-contract, execute, produce-artifact, verify-artifact, route-memory, emit-failure-receipt.

Layout

m87-governed-loop/
├── reference/m87-governed-loop.bpmn     # isExecutable=false — the spec
├── executable/m87-governed-loop.bpmn    # isExecutable=true  — Zeebe
├── policy/{governance_policy,tool_manifest}.yaml
├── workers/python/   governed_loop/{policy,gates,receipts,workers}.py + tests/
├── workers/java/     src/main/.../{Policy,Manifest,Gates,Receipts,Workers}.java + src/test/...
├── docs/invariant-mapping.md
└── .github/workflows/ci.yml

License

MIT © 2026 Mac McFall / M87 Studio LLC

About

Governed execution loop (Proposal ≠ Execution) in BPMN 2.0: dual reference + Camunda 8 executable model, fail-closed by construction, with Python + Java invariant proofs.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors