Integration by Field - Bit Build Forge Stacks and Layers

The Bit Build Forge does not integrate by merging. It integrates by giving disconnected work a shared field of structural standing.

Every complex build has an integration problem.

Not the technical kind — the information kind. Owner goals, designer intent, contractor execution, peer reviewer findings, commissioning results, RFI responses, punch items, closeout requirements. Each one produced by a different party, in a different format, at a different moment in the project. Each one sitting in its own document, its own folder, its own system.

The standard solution is to connect them. Build a dashboard. Link the documents. Create a shared drive. Run a coordination meeting. These efforts produce process visibility. What they rarely produce is structural clarity — an answer to the question: what does this piece of information actually mean, and where does it belong in the build?

The Bit Build Forge takes a different approach.

Not merging. Standing.

Most integration projects ask: can this tool talk to that tool? Can this database feed that dashboard? Can this document be linked to that workflow?

That produces brittle integration. The relationship is built between systems that were not designed to share meaning. When one changes, the connection breaks. When the project closes, the integration disappears.

The Forge asks a different question: what structural standing does each piece of work have?

Standing means: what layer does it belong to? What role does it play? What evidence supports it? What closes it? What witnesses it?

Once each piece of work has structural standing, integration follows naturally. Identity is declared. Role is declared. State is visible. Gaps are named. Relationships become comparable across roles and phases — not because everything is in one system, but because everything is in the same field.

What changes when review becomes field formation

A peer reviewer reads documents, compares drawings, inspects field conditions, remembers past problems, detects mismatches, and decides what matters. That is structural work. Most of it is tacit — held in the expert's head, expressed through judgment, lost when the project ends.

The Forge makes that work explicit.

A review comment becomes a coordination-risk Bit. A submittal decision becomes a product Bit validated against design intent. A site observation becomes a field-reality evidence Bit. A commissioning test becomes a performance-witness Bit. A punch item becomes a defect-resolution Bit, open until closed.

The activity has not changed. What changes is that the output has structural standing. It can be located. It can be acted on. It can be witnessed. It persists beyond the meeting where it was generated.

Review is no longer only a document activity. It becomes field formation.

The expertise claim

Human experts already do this mentally. They build a structural field in their heads over the course of a project — who said what, what was resolved, what is still open, what the owner actually cares about versus what the drawings say.

The Forge makes that field explicit and inspectable.

It turns tacit knowledge into declared Bits. It turns scattered review comments into field structure. It turns project memory into reusable patterns. It turns one-off expertise into structural standing that can be reviewed, transferred, and built upon.

That is why processing documents matters. The goal is not document summarization. The goal is to develop the field that holds the build together.

Without the Forge: information is scattered, status is interpreted manually, responsibility is diffuse, evidence arrives late, review repeats itself, project memory is weak.

With the Forge: each Bit has identity, each Bit has state, each Bit has evidence requirements, each Bit has closure conditions. Gaps are visible. Work is comparable across roles and phases.

That is not more process. It is less ambiguity.

The Bit Build Forge does not replace expertise. It captures and compounds it. It does not erase the differences between disconnected efforts. It makes those differences structurally useful.

They manage the build with documents. The Forge makes the build structurally visible, actionable, and provable.

— Dave / greenm3

Bits for the Build - deliver the essential information at the right place at the right time

The right information, at the right place and time, for the energy you have, to get the build done.

In the early 1990s the problem was that text on low-resolution screens was unreadable. Print fonts existed, but they were designed for print. They did not fit the medium.

The solution was named simply: fonts for the screen. Verdana solved that. The name made the problem and the answer obvious at the same time.

MakaiWay is trying to make the same move for a different problem.

Builds today — software builds, construction builds, commissioning steps, data center bring-ups — fail not for lack of data. Data is everywhere. They fail because the right information is not in the right place at the right time for the energy and context available. The person who needs to know something cannot act on what they are given, because what they are given is not shaped for them.

The answer to that is named the same way Verdana was named: Bits for the Build.

What is a Bit?

A Bit is a scoped, addressable unit of essential information needed to support a build. It is not a file. It is not a doc. It is not a database row. It is the smallest unit that advances the build.

Four properties define it.

Identity. Every Bit has an address. That address makes it verifiable — you can confirm it is what it says it is — and composable — it can link to other Bits. Without an address, information cannot be secured or connected. It can only be copied.

Fluid. The architect, the inspector, and the bricklayer asking the same question receive different Bits, because their build context is different. A Bit that answers the right question for the wrong person is noise.

Energy-aware. The right Bit accounts for what the receiver can actually do with it given current constraints — time, attention, available tooling. Information delivered outside the window where it can be used is not useful information. It is overhead.

Compile-ready. Bits combine. Linked Bits compile into the build. The ID makes relationships explicit instead of implicit. The build is what the Bits compile into.

The lifecycle

Every Bit moves through a visible state.

□ FIELD — the Bit has arrived. Available, scoped, addressable. Pending work.

△ MORPHISM — action is being applied. The build is moving.

○✕ CLOSURE + WITNESS — the Bit's contribution is complete and proven.

Squares are pending. Triangles are in motion. The circle-X is done and witnessed. Anyone looking at a wall of Bits can read the build state at a glance — not from a status dashboard, not from a standup, from the symbol set.

That last part matters. Most information systems deliver. Few witness. The X inside the closure is proof that the work happened — not that someone reported it happened.

Why this framing holds up

It names a problem nobody else has named. "Information delivery" is too generic. "Documents" is too static. "Bits for the Build" points at the gap.

It carries the verification model in the symbol set. You do not need to read the spec to understand that ○✕ means closed and proven. The proof is in the shape.

It scales. A Bit's ID and links are the same whether the build is a meeting, a data center commissioning step, or a code change. The model does not depend on the size of the build.

It respects energy. The same fact, delivered as the wrong Bit at the wrong time, is noise. Energy is a first-class input, not an afterthought.

Verdana solved legibility on screens. MakaiWay solves delivery and verification for the build. People grab "Bits for the Build." Everything else unfolds from there.

— Dave / greenm3

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