Cause and Effect Is the Hard Part

Most monitoring systems tell you what happened. GreenM3DC is trying to preserve enough structure to say why.

Every data center has sensors. Most of them are wired into a Building Management System that watches thresholds and fires alarms when something crosses a limit. That part works. It has worked for decades.

What it cannot do is tell you why.

A chiller alarm fires. The value crossed the limit. But was it caused by ambient temperature? A control loop that stopped responding? Maintenance that shifted the baseline two weeks ago? The alarm gives you the event. It does not give you the cause.

GreenM3DC is built around a different question: can we preserve enough structure in the data to identify cause and effect? Not just log that something happened, but retain the relationships that explain it.

That sounds straightforward. It is not.

Three things you need before cause and effect is possible

1. Independent witness paths

One sensor reading can be noise. One sensor reading from a second independent path that confirms the same finding — that is evidence.

GreenM3DC requires at least two independent witness paths before it will report a structural finding. Not two readings from the same sensor family. Two structurally independent routes to the same conclusion.

This is not a statistical trick. It is the minimum condition for calling something a cause rather than a coincidence.

2. A governing model to compare against

You cannot say a system is drifting unless you know what it looks like when it is not drifting.

GreenM3DC holds a governing model — a declared set of relationships that define how a healthy system responds to its environment. Is the chiller still responding to outdoor wet-bulb temperature the way it should? Is IT load still producing the expected facility power draw?

Without a governing model, you can measure divergence. You cannot say whether it is meaningful.

The governing model is not learned from the data. It is declared. That distinction matters. A model learned from drifted data will treat the drift as normal. A declared model holds the standard against which drift is measured.

3. Temporal provenance

When did the relationship break?

A finding without a timestamp is not causal evidence. GreenM3DC tracks the age of each divergence — how long each relationship has been silent, not just whether it is silent now. That age is part of the drift calculation.

This is what allows questions like: did this start before or after the maintenance event? Did the chiller response degrade gradually or suddenly? The temporal record has to be preserved, not aggregated away.

Confidence is declared, not assumed

GreenM3DC does not report findings without a confidence class. Every structural finding comes with a declared confidence level: LOW, MEDIUM, or HIGH.

The current pilot runs on synthetic data with a single-fault injection. Everything is LOW confidence — correctly so. One witness path in a controlled dataset is not the same as two independent paths in a live system under real operating conditions.

That declaration is the point. A system that reports HIGH confidence from a single sensor, or from a dataset that was never admitted against a real baseline, is not being honest about what it knows. GreenM3DC forces the confidence to be stated before the finding is reported.

Transparency is the architecture

GreenM3DC publishes its governing model, its morphism pairs, its confidence classes, and its baseline requirements. Not as documentation written after the fact — as structural objects that have to be satisfied before a finding is admissible.

This is what "open and transparent information architecture" means in practice. It is not a claim about values. It is a constraint on what the system is allowed to report.

If you cannot show which relationships are being evaluated, which baseline the drift is measured against, and what confidence the finding carries — you have not identified a cause. You have identified an anomaly and called it a cause. That is the mistake most systems make.

Cause and effect is hard because it requires more than data. It requires structure: independent witnesses, a governing model, temporal provenance, and declared confidence. Most monitoring systems are not built to preserve that structure. They are built to detect events.

GreenM3DC is built to preserve the structure. Whether it succeeds is a question the production data will answer.

When Three Languages Agree: Building a Registry-Governed Structural Compiler

Most multi-language projects settle for behavioral equivalence: run the same test against two implementations, check that the outputs match, ship. This works — but it has a quiet weakness. Behavioral equivalence is defined by the test author, and the test author can be wrong. Verdicts can match when implementations share the same bug. And the moment you change one implementation, you have to remember to update all three with no mechanical way to verify alignment.

We wanted something stronger: a verifiable structural witness, not just a behavioral test.

The Canonical Hash

The insight that unlocked the design: if two implementations produce the same canonical gate-vector bytes for the same fixture, they have performed the same structural evaluation for that declared domain — regardless of language.

We defined a canonical output format called the gate vector:

gate_id:bool|gate_id:bool|...

Sorted lexicographically by gate ID, lowercase boolean, joined by |. A fully-passing WCGD admission produces:

F01:true|F02:true|F03:true|F04:true|F05:true|F06:true|F07:true|F08:true|F09:true|F10:true|F11:true|F12:true|FAP:true

Then we hash it: SHA256 of the UTF-8 encoding of that string, first 16 hex characters. That's the output hash.

The output hash for a fully-passing WCGD fixture is 50652a5823a2c420. In Python, in Swift, in Rust. Same bytes. Getting there was not simple.

What the Hash Actually Witnesses

A matching hash is not magic. It is a compact witness that several structural decisions aligned at once:

Gate identity: Both implementations resolved the same gate IDs. A different ID produces a different vector string.

Field mapping: Both implementations read the same fixture field for each gate. A wrong field mapping produces a different boolean, different string, different hash.

Sort order: Both sorted gates lexicographically. A different order produces a different string.

Boolean representation: Both used lowercase true/false. Python's str(True) produces "True" — capital T. That was one of our early bugs: Python and Swift diverged because of one character. Fixing it required adding .lower() to Python serialization and codifying the requirement as CR-LAW-04 — canonical bool representation is lowercase.

Once all four levels align, the hash is forced to be identical. The definition leaves nothing to interpretation. The bytes either match or they don't.

The Registry Is the Law

Every gate has a canonical morphism ID, defined in a single JSON file:

{
  "morphism_id": "morph.wcgd.f07.numeric_tolerance",
  "gate_id": "F07",
  "fixture_field": "numeric_tolerance",
  "morphism_type": "DECLARE"
}

No implementation is allowed to define gate identities locally. If Swift uses makai.gate.f07 instead of morph.wcgd.f07.numeric_tolerance, that is a compliance violation — not a naming preference — and it surfaces immediately as a hash mismatch. This happened exactly once during development. The registry caught the bug automatically.

The three languages bind to the registry in three different ways:

Python loads it at runtime as a dict keyed on canonical morphism IDs.

Swift encodes it as a static array in PathBEvaluator.expectedGates. In the current implementation, convergence tests enforce that it stays synchronized with the canonical JSON.

Rust takes the most structurally robust approach: the registry is compiled into const arrays at build time via build.rs:

// build.rs — runs during cargo build
let registry_path = PathBuf::from(&manifest_dir)
    .join("../../compiler_registry/morphism_registry.json");

println!("cargo:rerun-if-changed={}", registry_path.display());

// reads JSON, generates:
// pub const WCGD_MORPHISMS: &[(&str, &str, &str, &str)] = &[
//   ("morph.wcgd.f01.spec_identity", "F01", "spec_id_stable", "VERIFY"),
//   ...
// ];

If morphism_registry.json changes and the field names no longer match the fixture structs, cargo build fails — before any test runs, before any binary ships. You cannot accidentally ship a Rust binary that disagrees with the registry.

The Convergence Matrix

We track cross-language convergence in a JSON file. Each entry records whether two implementations produce identical output hashes across all fixture classes. The snippet below shows three of the five fixture classes:

{
  "path_a_lang": "python",
  "path_b_lang": "rust",
  "status": "ADMITTED",
  "fixture_results": {
    "wcgd_admitted": { "convergence": true, "hash_a": "50652a5823a2c420", "hash_b": "50652a5823a2c420" },
    "wcgd_refused":  { "convergence": true, "hash_a": "4cd3fd807d0169bb", "hash_b": "4cd3fd807d0169bb" },
    "sc_admitted":   { "convergence": true, "hash_a": "3e4aa232097f1392", "hash_b": "3e4aa232097f1392" }
  }
}

The matrix covers all six language pairs (Python×Python, Swift×Swift, Rust×Rust, Python×Swift, Python×Rust, Swift×Rust) and all five fixture classes (WCGD admitted, refused, gap, and Sensor Commissioning admitted and refused). That is thirty independently checkable convergence entries.

All thirty: ADMITTED.

The matrix is not a test suite. It is a structural record. Each entry is independently verifiable: anyone with the three CLI binaries can run the same fixture and compare hashes. The hashes are the canonical output of the system, defined precisely enough that there is no room for disagreement.

MW-13: The Compiler Never Throws

One law applies to all three implementations equally: MW-13 — MakaiCompile never throws to its caller. Every evaluation always produces a complete verdict, even when something goes wrong. An unregistered morphism ID doesn't crash — it emits a GateResult with passed: false and refusal_code: "MORPHISM_ID_UNREGISTERED". The caller always gets a verdict. This matters for production systems where you want compile results to be inspectable even when the registry is partially invalid.

Behavioral Parity vs. Structural Admission

Behavioral parity — the weaker claim — means two implementations produce the same verdict on the same inputs. It can be achieved by coincidence, by sharing underlying code, or by writing tests that happen to cover the cases where implementations agree. It breaks silently when one is updated.

Language-independent structural admission — the stronger claim — means each implementation independently evaluates a shared morphism registry, and the results are witnessable as identical because the canonical form is defined to be unambiguous. If the hashes match across all fixture classes, the implementations read the same morphisms, mapped to the same gates, applied the same fixture fields, and serialized in the same canonical order.

The system has moved from "these things behave the same" to "these things are structurally the same computation, verified independently by three language runtimes and three SHA2 implementations."

That is the milestone.

What's Next

Live sensor data. Sensor Commissioning is currently running against synthetic fixtures. The next phase connects it to real sensor readings, where gate values come from actual commissioning events.

Postgres as the live registry source. Right now the JSON is authoritative and Postgres mirrors it. Eventually the direction reverses: the database is the source of truth, the JSON is generated from it. The compiler registry becomes live, auditable, database-backed.

More domains. WCGD Phase F and Sensor Commissioning are the first two structural domains. The morphism registry is designed to be extended — new domains add entries, never mutate existing ones. The convergence infrastructure is ready for them.

MakaiCompile is part of the MakaiWay structural information system.

Left Brain, Right Brain, and the Data Center

Most data center monitoring runs on sequential execution only. The parallel compute is already there, waiting. GreenM3DC is not about adding parallel — it is about achieving the right balance between the two.

In the last post, Gary Starkweather replaced white light with a laser. But he did not throw away his eyes. Incoherent light is how you see the room. Coherent light is how you write precisely onto a surface. You need both. The question is what each one is for.

The same duality runs through how a data center computes.

Two kinds of work

Sequential work is dependent. Step N cannot execute before step N-1 completes. A gate decision that requires the previous verdict. A threshold check against a current reading. This work belongs on a CPU — ordered, control-flow-heavy, low-latency.

Parallel work is independent. Element i's computation does not depend on element j's result. Evaluating divergence across thousands of sensor events. Detecting whether a morphism has been silent across a window of data. Each event can be evaluated without knowing what any other event produced. This work belongs on a GPU — unordered, high-throughput, data-flow-heavy.

Most monitoring systems treat all work as sequential. Every alarm threshold checked in a loop. The GPU is sitting there. It is not being asked.

The mistake is not using the wrong tool. It is not using both.

A CPU running parallel-eligible work produces correct results — slowly, leaving capability on the table.

A GPU running sequential-dependent work is worse than slow. Dependent computation on a parallel executor produces incorrect results silently. No alarm fires. The error is structural.

This is why the balance cannot be assumed. It must be governed.

GreenM3DC: both in balance

The compile loop — gate decisions, sequential verdicts — runs on the CPU. Dependent work. Each step requires the last.

The drift integral — detecting morphism silence across thousands of events — runs on the GPU. Each divergence calculation is independent. Embarrassingly parallel. The GPU processes the full window simultaneously; the CPU collects the result into a single structural finding: drift_excess, confidence class, morphism pairs in native units.

Neither replaces the other. The CPU asks: did this event pass the gate? The GPU asks: has this morphism been silent for six hours while the system continued to produce readings?

Different questions. Different execution. Running both correctly is what makes the full picture available.

The bridge between them has one rule: coupled computation cannot cross to the parallel side. If elements depend on each other, they stay on the CPU. The Fubini gate governs the crossing. Getting the boundary right is not a performance optimization — it is the architectural condition for both sides working correctly.

Starkweather needed coherent light to write precisely. He needed incoherent light to see the room. The insight was not to replace one with the other. It was to know which one to use, and when.

The GPU is already there. The question is whether you are asking it the right questions.

GreenM3DC is operational against the synthetic pilot dataset.
Production scoring requires real-sensor intake and an admitted baseline.

— Dave / greenm3

GreenM3DC's Focus on Delivering, borrowing Gary Starkweather's method inventing the Laser Printer

Coherence and focus

Published: 2026-04-28

Gary Starkweather was solving an information transfer problem.

The original problem was straightforward: Xerox wanted to send a copy from one copier to another. Transfer the image across a wire. Starkweather worked on it and ran into the same wall anyone would hit: white light is incoherent. Every photon is at a different phase, a different frequency, going a different direction. You cannot preserve precise spatial information on an incoherent carrier without the signal degrading. The image degrades. The signal falls apart before it arrives.

A laser is different. Its photons are coherent: same phase, same frequency, same direction. The source is coherent. And once you have a coherent source, you can use optics to focus it — direct it exactly where it needs to go, pixel by pixel, without loss. The laser solved the coherence problem that white light could not.

Then Starkweather saw the deeper thing. If you are sending a coherent signal anyway, why carry the entire image? A fax sends the complete picture — every pixel, whether it matters or not. But a coherent digital signal can carry structure: the information that describes the image, not the image itself. Send the structure. Render it on the receiving end. The result is more precise, faster, and far more efficient than copying the whole surface and transmitting it. That insight is the laser printer. Not a better copier. A new class of machine: one that transfers structured information and renders it onto a physical surface.

GreenM3DC is solving the same class of problem.

A construction project generates structural information continuously — material locations, RFI status, delivery provenance, thermal boundary conditions at mechanical interfaces. That information exists. The problem is that it is incoherent: scattered across systems, held by different teams, expressed in different formats, and never compiled into a single structured transfer that a decision-maker can act on. The owner does not lack data. The owner lacks a focused surface. Without that surface, the project cannot distinguish noise from structural signal.

GreenM3DC is the transfer mechanism. Each framework in the stack is a coherent lens — calibrated to one layer of the physical system, aimed at one class of structural claim. The spatial compiler is the optics. It takes those coherent inputs and focuses them onto a surface at the scale where a human can see what needs attention. The compile result is not trying to be a complete model of the building. It is a focused transfer of the building's own admitted signals, structured through a coherent grammar, rendered at the resolution where an owner can make a decision.

The Structural MRI Scanner is one tool in that transfer chain.

Just as an MRI in healthcare produces a diagnostic scan — not a treatment, not a care plan, but a precise localization of where the body is incoherent — the Structural MRI Scanner produces a structural scan of the project field. Four anomaly classes. Fifteen findings. Thermal boundary stress at the perimeter interfaces where mechanical rooms connect to outside chiller infrastructure. Material staged in the wrong location. Design blocked waiting on RFI resolution. Delivery status unknown. The scanner does not find generic issues. It transfers typed, localized incoherence onto a surface the project team can read.

The value is not that it finds problems. Project teams already know problems exist. The value is that it separates problem types by structural cause, localizes them in the field, and identifies which gate cannot truthfully close until the incoherence is resolved.

Once a boundary is identified, resolution can be compiled.

Each corrective action runs through the GreenM3DC compiler against the specific gate it is meant to close. A gate passes when its conditions are structurally met — not when someone marks it resolved. This is not a 100% project approval. It is a gate-by-gate compile: the gates that have been identified, tracked, and run. Some pass. Some do not. The ones that do not tell you exactly what still needs to close.

That is Starkweather's principle applied to infrastructure. He did not make printing faster. He built a mechanism that could transfer structured information from a coherent digital source onto a prepared physical surface. GreenM3DC does not make project reporting faster. It builds a mechanism that transfers structural information from a coherent compile stack onto a decision surface an owner can act on.

Structural MRI turns project uncertainty into typed, localized, business-actionable incoherence. The blur is where you point next.

GreenM3DC is a structural analysis project applying compile-time verification to green data center design. The sensor bridge is admitted. The spatial compiler is running. Phase 2a — EFC identification, the feedback-control lens — is next in the stack.

Green = Sustainable -> Compiler

Green Is a Compiler

The standard green data center question is: Is this facility green?

That is the wrong question. Too easy to answer badly.

The better question is: Can these green conditions be sustained?

That is a compiler question. A compiler takes declared inputs, checks them against rules, and returns a verdict — not a score, not a certification. A gate decision: PASS, FAIL, or UNKNOWN.

Green = Sustainable

Green means sustainable.

Not efficient today. Not renewable on paper. Not carbon neutral by accounting convention.

Sustainable means the conditions that make the facility green can be held over time, as the world changes around it. That one move changes everything — because a lot of things that currently pass as green stop compiling.

Lowest energy use may not be sustainable. A facility running PUE 1.05 on free-air cooling is impressively efficient. But some of that efficiency is borrowed from the climate envelope around it. If that envelope shifts over the operating life of the building, the free-air window narrows and the PUE climbs. The efficiency was not built into the system. It was leased from the atmosphere.

Renewable may not be sustainable. Hydro depends on watershed conditions. Solar depends on manufacturing, degradation, and end-of-life. Wind depends on grid integration and geography. RECs are accounting tools, not physical supply by themselves — a REC can match consumption on paper while the facility draws fossil generation at 2am. The electrons do not care about the certificate.

None of this means renewable energy is bad. It means the sustainability compile is more demanding than the green checklist.

Compiler Outputs

PASS — the claim holds across the declared time horizon, boundary, and stress conditions.

FAIL — the claim does not hold, or a prohibited dependency appears.

UNKNOWN — the witnesses are missing. The compile cannot run.

UNKNOWN is not a soft PASS.

What the Compile Checks

For GreenM3DC, the compile uses four structural checks.

INV — what must remain true

PUE must remain below a declared threshold, measured at the meter, not modeled at design. Renewable fraction must be matched to actual consumption, not just annual average. Carbon accounting must close within a declared reporting window.

NINV — what must never occur

Fossil fuel must not become the primary power source while the facility still claims to be green. Cooling capacity must not fall below heat load — thermal runaway is not a warning, it is a compile failure. Carbon neutrality must not rest entirely on purchased offsets with no internal reduction pathway.

BOUND — where the claim holds

Free-air cooling efficiency is valid only within a declared ambient range. Outside that range the PUE claim does not compile — the model has left its boundary. The renewable claim holds at this grid location, with these generation sources, under these matching rules — not universally.

MORPH — what must be able to change

When ambient conditions exceed the free-air cooling threshold, the mode must shift from free-air to mechanical cooling. That transition must be declared and tested, not assumed. When the primary renewable source degrades, there must be a declared substitution path — not a future intention, a structural commitment.

These are four examples — one per category. The full GreenM3DC compile is built to run over dozens of tests across the same four categories.

The point here is the structure. The list is the work.

Most facilities would not return PASS or FAIL on this compile. They would return UNKNOWN.

Not because they are failing, but because the witnesses are missing. No declared time horizon. No stress scenario. No lifecycle assessment of the hardware fleet.

UNKNOWN is not green. UNKNOWN is not sustainable.

Can you run this compile?

INV PUE_THRESHOLD · RENEWABLE_MATCH · CARBON_WINDOW

NINV FOSSIL_PRIMARY · COOLING_FLOOR · OFFSET_ONLY

BOUND FREE_AIR_ENVELOPE · RENEWABLE_LOCALITY · LOAD_DENSITY

MORPH COOLING_MODE_SHIFT · SOURCE_SUBSTITUTION · HARDWARE_EOL

Next: The IT asset list as structural input — what the BOM actually tells you about whether a facility can be sustained.