Building Isolyne (Part 3): Testing State Supersession and Idempotent Replay in a CQRS Event Engine

In hackathons and fast-moving software development, teams often treat automated testing as an afterthought. The usual justification is: “We’ll write tests after the demo works.”

When we set out to build Isolyne for Shipaton 2026, we inverted that rule.

Because Isolyne’s core value is catching silent architectural drift, the kernel cannot afford a single false positive or phantom alert. If our engine flags a false disagreement when a developer simply changed their mind, the team loses trust in the radar. If it drops a real conflict because of a race condition, the app fails its primary purpose.

To ensure our CQRS event engine behaved as designed, we codified 10 Ironclad Invariants and wrote an automated suite using Vitest that runs in < 100 milliseconds.

Here is how we tested the edge cases that break traditional state machines.

Invariant 1: Supersession (Changing Your Mind)

The Rule: If a single developer states a choice and later states a different choice on the same topic, the new decision supersedes the old one. It must not trigger a conflict with their own past self.

it('Invariant: Alice -> Redux, Alice -> Zustand => no gap (supersession)', async () => {
  const { kernel, adapter } = setupKernel();

  // Alice states Redux at T1
  await kernel.processSignal({
    id: "s1",
    squadId: "inv2",
    actorId: "Alice",
    type: "decision_stated",
    timestamp: "T1",
    payload: {
      topic: "State",
      choice: "Redux"
    }
  });

  // Alice updates her choice to Zustand at T2
  await kernel.processSignal({
    id: "s2",
    squadId: "inv2",
    actorId: "Alice",
    type: "decision_stated",
    timestamp: "T2",
    payload: {
      topic: "State",
      choice: "Zustand"
    }
  });

  const ev = await adapter.loadActiveProposal("inv2");

  // Invariant assertions: No gap, exactly 1 active decision, latest choice preserved
  expect(ev.selectedGap).toBeNull();
  expect(ev.state.decisions).toHaveLength(1);
  expect(ev.state.decisions[0].choice).toBe("Zustand");
});

Invariant 2: Gap Evaporation (Silent Self-Correction)

The Rule: If Alice chooses PostgreSQL and Bob chooses MongoDB, a consensus gap exists. If Bob later aligns with Alice on his own, the gap must evaporate automatically without requiring manual ticket closures or status flags.

it('Invariant: State-machine edge case: Bob changes mind to align, gap evaporates', async () => {
  const { kernel, adapter } = setupKernel();

  // Drift: Alice -> Postgres, Bob -> Mongo
  await kernel.processSignal({
    id: "s1",
    squadId: "evap",
    actorId: "Alice",
    type: "decision_stated",
    timestamp: "T1",
    payload: {
      topic: "DB",
      choice: "Postgres"
    }
  });

  await kernel.processSignal({
    id: "s2",
    squadId: "evap",
    actorId: "Bob",
    type: "decision_stated",
    timestamp: "T2",
    payload: {
      topic: "DB",
      choice: "Mongo"
    }
  });

  let ev = await adapter.loadActiveProposal("evap");
  expect(ev.selectedGap?.type).toBe('consensus_gap');

  // Bob aligns voluntarily at T3
  await kernel.processSignal({
    id: "s3",
    squadId: "evap",
    actorId: "Bob",
    type: "decision_stated",
    timestamp: "T3",
    payload: {
      topic: "DB",
      choice: "Postgres"
    }
  });

  ev = await adapter.loadActiveProposal("evap");
  expect(ev.selectedGap).toBeNull(); // Gap evaporates cleanly
});

Invariant 3: Idempotent Replay (Re-evaluating Without Side Effects)

The Rule: Evaluating a squad multiple times consecutively must produce the exact same divergence state without generating duplicate alerts, memory leaks, or ghost events.

it('Invariant: EvaluateSquad is idempotent (no duplicate divergence markers)', async () => {
  const { kernel, signalRepo } = setupKernel();

  await kernel.processSignal({
    id: "s1",
    squadId: "idem",
    actorId: "Alice",
    type: "decision_stated",
    timestamp: "T1",
    payload: {
      topic: "DB",
      choice: "Postgres"
    }
  });

  await kernel.processSignal({
    id: "s2",
    squadId: "idem",
    actorId: "Bob",
    type: "decision_stated",
    timestamp: "T2",
    payload: {
      topic: "DB",
      choice: "Mongo"
    }
  });

  // Evaluate the squad twice consecutively
  await kernel.evaluateSquad("idem");
  await kernel.evaluateSquad("idem");

  const signals = await signalRepo.getBySquad("idem");
  const divergences = signals.filter(
    s => s.type === 'divergence_detected'
  );

  // Exactly 1 divergence event recorded, not 2
  expect(divergences).toHaveLength(1);
});

Invariant 4: Priority Ordering (Ownership Precedes Consensus)

The Rule: A project without an assigned owner is a structural risk that takes precedence over individual technical disagreements. The engine must surface and resolve Ownership Gaps before evaluating Consensus Gaps.

it('Invariant: Pipeline: Ownership + Consensus coexist & resolve in order', async () => {
  const { kernel, adapter } = setupKernel();

  // Squad of 2 without an owner
  await kernel.processSignal({
    id: "j1",
    squadId: "pipe1",
    actorId: "Alice",
    type: "member_joined",
    timestamp: "T0"
  });

  await kernel.processSignal({
    id: "j2",
    squadId: "pipe1",
    actorId: "Bob",
    type: "member_joined",
    timestamp: "T0"
  });

  // Conflicting choices
  await kernel.processSignal({
    id: "s1",
    squadId: "pipe1",
    actorId: "Alice",
    type: "decision_stated",
    timestamp: "T1",
    payload: {
      topic: "DB",
      choice: "Postgres"
    }
  });

  await kernel.processSignal({
    id: "s2",
    squadId: "pipe1",
    actorId: "Bob",
    type: "decision_stated",
    timestamp: "T2",
    payload: {
      topic: "DB",
      choice: "Mongo"
    }
  });

  let ev = await adapter.loadActiveProposal("pipe1");

  // Step 1: Ownership gap takes priority
  expect(ev.selectedGap?.type).toBe('ownership_gap');

  // Step 2: Resolve ownership
  await adapter.respondToProposal(
    "pipe1",
    "Alice",
    "agree",
    ev.proposal!.id,
    ev.selectedGap!.id,
    {
      type: 'ownership',
      ownerId: 'Alice'
    }
  );

  // Step 3: Now the Consensus gap surfaces
  ev = await adapter.loadActiveProposal("pipe1");
  expect(ev.selectedGap?.type).toBe('consensus_gap');
});

The Complete Invariant Matrix

Our full test suite guarantees:

#

Invariant Tested

Expected Behavior

1

Direct Contradiction

Alice: Postgres vs Bob: Mongo →→ triggers consensus_gap

2

Supersession

Alice: Redux →→ Alice: Zustand →→ updates belief, zero gaps

3

Commitment Drift

Team agrees on Postgres, Alice later states Mongo →→ flags drift

4

Unanimous Alignment

Alice: Postgres + Bob: Postgres →→ zero false contradictions

5

Structured Evidence

Gap payload contains exact verbatim strings and distinct choices

6

Challenge State Machine

Challenging an alignment proposal leaves the gap open for debate

7

Evaluation Idempotency

Multiple evaluations produce identical state without duplicate signals

8

Gap Evaporation

Voluntary alignment silently resolves the conflict

9

Pipeline Priority

Structural ownership gaps resolve before technical consensus

10

Deterministic Hashing

Safe alphanumeric gap IDs prevent distributed collisions

Safe alphanumeric gap IDs prevent distributed collisions

$ npm test

RUN v4.1.10 /Users/abhi/PROJECTS 2/HACKOS

✓ src/kernel/tests/kernel.test.ts (10 tests) 1ms
✓ src/services/__tests__/llmParser.test.ts (4 tests) 2ms

Test Files  2 passed (2)
Tests       14 passed (14)
Duration    95ms

The RevenueCat Connection: Why Invariants Protect Monetization

Why does this matter for our RevenueCat integration and the HAMM Award?

In Isolyne, the Pro tier unlocks the Audit-Ready Project Timeline—a complete chronological history of every architectural pivot, ownership assignment, and consensus agreement.

If our state machine allowed race conditions, duplicate events, or silent state corruption:

  • The exported decision logs would be unreliable.
  • Paying subscribers wouldn’t get a true source of truth.
  • Entitlements and event replays would desynchronize across client restarts.

By testing our 10 invariants with automated Vitest suites, we gain confidence that when a user upgrades via RevenueCat, the timeline they unlock behaves consistently under the scenarios we tested.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.