Case Study: The Clocks Looked Identical. They Belonged to Different Domains.

Same name. Same frequency. Same phase. Same edge schedule.

The connection was still invalid.

The compiler rejected it during package validation, before simulation was required, because the logic on either side belonged to different structural clock domains.

We paired that rejected connection with a nearby valid one. A local signal passed through two bitwise inversions, preserving its value, and then fed two consumers. The local neighbor required the local clock owner. The target required a peripheral clock owner. Preserving the bits did not change that distinction.

This is a deterministic architectural experiment, not a blinded autonomous-debugging evaluation.

1. Every Cosmetic Repair Left the Connection Invalid

Both clocks already had identical readable names and declared scheduling attributes. We then tried renaming them together, rescheduling them together, and shifting their first edges together.

None of those changes made the target connection valid. The neighboring control continued to pass.

Before correction, the neighbor was checked in a separately validated control. The final accepted design contained both the target and the neighbor. The distinction matters: checking a valid control does not partially validate a rejected design.

Matching clock schedules did not make the connection valid. The relevant distinction was which clock domain owned the participating logic.

Here, ownership means the declared clock-domain identity associated with the logic. It is part of the connection's structural contract. Matching schedule attributes do not, by themselves, establish that two declarations identify the same domain.

The illustration describes logical schedules, not measured physical clocks. It does not establish a common physical clock source, zero skew, or a safe physical clock-domain crossing.

2. The First Rejection Was Correct—but Not Yet Actionable

The first attempt already rejected the connection. What it lacked was enough structured information to investigate the failure without interpreting diagnostic text.

That was a real limitation, and we retained the original rejection in the experiment's records. We then improved diagnostic visibility while keeping the validity rule unchanged. The tooling became more useful to automation without making the compiler more permissive.

The compiler returned structured evidence identifying the source binding and the two distinct clock-domain owners involved. The investigation could use that evidence to examine the specific connection that failed.

The invalid design stayed invalid. It was not exposed as though it were a verified design graph. Instead, the investigation used a separately compiled valid control to examine candidate source expressions and their clock ownership. Only one candidate had the destination domain required by the rejected connection.

The control and the rejected design remained distinct artifacts. Facts from the control were not presented as facts from a verified version of the rejected design. That boundary was preserved throughout the investigation.

For automation, a rejection needs to be useful without turning unverified information into trusted design state.

3. Correct the Connection, Preserve the Neighbor

The accepted change reconnected the target to the fixture-specified source for its peripheral domain. Fresh validation confirmed the required ownership on both sides of that connection. The local neighbor retained its original ownership relationship.

The fixture supplied the intended data-routing relationship. The investigation's source-selection hypothesis was deliberately narrow: one available source had the required owner. An absent or ambiguous compatible source stopped the experiment instead of inviting a guess.

Ownership compatibility alone does not establish functional correctness of an arbitrary reconnection. Changing the source changes where the data comes from. The result demonstrates a constrained correction in this fixture, not a general ability to infer routing intent from clock metadata.

That limit is also what makes the candidate matrix informative. Changing names or timing attributes left the violated requirement untouched. Selecting the intended source changed the ownership relationship that validation was actually checking.

4. An Edit Must Still Apply to the Design in Front of It

The correction touched only the rejected connection. It was checked against the source revision and expected content before application, then validated on the resulting design with both connections present.

We subsequently attempted to apply the original edit again to the modified source. It was rejected as stale.

Structural compatibility and edit applicability are separate questions. A connection can be valid in principle while an old edit no longer describes the current source. An automated workflow needs evidence for both.

5. Rename the Clocks. Add a Lookalike. Repeat.

A demonstration can succeed because its labels make the answer obvious. We therefore reran the experiment after renaming clocks, instances, and values, shifting source positions, and inserting a similar-looking source with the wrong owner.

The investigation still selected the source with the required ownership and rejected the lookalike. The cosmetic-renaming candidate remained an actual rename in the perturbed case, rather than accidentally becoming a no-op.

A complete repeat reproduced 160 generated artifacts byte-for-byte. An independent checker reconciled the recorded failure, candidate outcomes, corrected connection, preserved neighbor, and stale-edit rejection. The original, less informative rejection remained separately preserved.

The checker validated the experiment's recorded relationships; it was not a second general CDC verifier. Reproducibility supports the bounded result. It does not establish signoff coverage or performance at scale.

6. The Boundary of the Result

The fixture and repair hypothesis were authored for this experiment. No LLM ran inside the investigation loop. The result does not measure an unfamiliar agent's ability to discover an undisclosed defect or infer a specification.

Within that scope, the experiment established that:

• An ownership mismatch remained a construction-time error even when every declared scheduling attribute matched.
• Structured failure evidence supported a targeted investigation without relaxing the validity rule or treating the invalid design as verified.
• The intended correction passed with the neighboring connection preserved.
• The result survived the tested renaming and lookalike perturbations, reproduced byte-for-byte, and rejected a stale edit.

This is structural clock-domain ownership validation. It does not establish metastability behavior, synchronizer adequacy, mean time between failures, physical skew, generated-clock timing correctness, CDC signoff, or equivalence to commercial CDC tools. Nor does it establish functional correctness for arbitrary reconnections.

The failure occurred before execution. That does not make simulation or physical CDC analysis unnecessary for an accepted design; it identifies a class of structural mistake that this experiment rejected earlier in the flow.

Four Experiments in Preserving Design Meaning

The case studies examine different ways hardware can look plausible while violating its requirements:

• FIFO: preserve identity through transformation.
• Transaction: preserve ownership through history.
• Numeric: preserve meaning through arithmetic policy.
• Clock: enforce structural identity before execution.

The clock experiment adds a useful dimension to that progression. A rejected design can still provide precise grounds for investigation, while remaining rejected. Better failure evidence can make automation more capable without weakening what the system is willing to accept.

Memdance is building an AI-native hardware engineering stack around these relationships. Our goal is to give engineers and engineering agents a dependable basis for investigating failures, reviewing changes, and deciding what the available evidence actually supports.

Reliable automation starts with preserving the distinction between a plausible connection and a valid one.