Vortex Vote

Let a vote be an element of the loosely-typed set {accept, reject, true, false, yes}, which the module treats as a coerced boolean via hasQuorum and inline filter predicates. Each path P is a function

P : V₁ × V₂ × ... × Vₖ  →  Outcome × Details

where each Vᵢ is a fixed-arity vote vector, and Outcome ∈
  { ABORT, COMMIT, ROLLBACK, RECONCILE, HOLD, HUMAN_REVIEW, DELAY_AND_AUDIT, SAFE_COMMIT }

A central structural property holds across all three paths: they are total functions. Every reachable input — including malformed or under-length vote arrays — produces a defined outcome, never an exception or an undefined branch (hasQuorum and allGatesClear both return false on missing or short arrays, rather than throwing). This is a minimal but real correctness guarantee: closer to exhaustiveness in the state-machine sense than to liveness in the CAP-theorem sense, but it does mean the decision procedure cannot stall in an undefined state.

quorum(primary, k=3)  ∧  |{accept ∈ stabilizers}| ≥ ⌈4·(1/3)⌉

Structurally, this is a conjunction of a unanimity gate and a plurality gate — not a single quorum system but a cascade of two. The first stage, hasQuorum(primary, 3) called with min = length, is effectively unanimity among the 3 primary voters — a strictly stronger requirement than the majority quorum (⌈n/2⌉+1) used in classical systems such as Paxos. The second stage relaxes the bar to ⌈4/3⌉ = 2, i.e., a plurality rather than a majority.

This asymmetry — a strict unanimity gate feeding a comparatively weak downstream check — is the formal expression of the design intent: "fast, but only for low-stakes decisions." The expensive check (unanimous primaries) is cheap to fail early; the cheap check (2-of-4 stabilizers) is what actually governs the commit/rollback boundary.

quorum(seeds, k=3)  ∧  passes(auditRounds=9, majority(validators)) ≥ 7

This is the most analytically interesting path. runCyclicAudit re-evaluates the same static validators array across 9 iterations:

for (let i = 0; i < auditCount; i++) {
  const acceptCount = validators.filter(
    (v) => v && (v.vote === "accept" || v.vote === true)
  ).length;
  rounds.push(acceptCount > validators.length / 2);
}

Since validators never mutates between iterations, all 9 rounds are deterministically identical — the result is passes ∈ {0, 9}, never anything in between, under the current implementation. In a genuine cyclic-audit design — repeated sampling under noise, or re-polling live agents whose votes can plausibly flip between rounds — one would expect a distribution over passes ∈ [0, 9]. As written, the function is a majority check dressed as an iterative protocol: the loop currently has no independent source of variance per round.

Unlike the Fast and Middle paths, the Slow Path is best modeled as an ordered rule list — closer to a firewall ruleset or a cond expression than to a quorum system. The order in which its four checks run is the specification:

INPUT: { stateVotes, gateChecks, entropyBufferTriggered }
        │
        ▼
 ┌─────────────────────────┐   fail   ┌────────┐
 │ allGatesClear(4/4)?     ├─────────▶│  HOLD  │   ← safety precondition, unconditional block
 └───────────┬─────────────┘          └────────┘
          pass│
          ▼
 ┌─────────────────────────┐   yes    ┌────────────────┐
 │ any vote === ESCALATE?  ├─────────▶│  HUMAN_REVIEW  │  ← liberal veto: one dissenter wins
 └───────────┬─────────────┘          └────────────────┘
           no│
          ▼
 ┌─────────────────────────┐   yes    ┌───────────────────┐
 │ entropyBufferTriggered? ├─────────▶│  DELAY_AND_AUDIT  │  ← unconditional deliberate delay
 └───────────┬─────────────┘          └───────────────────┘
           no│
          ▼
 ┌──────────────────────────┐   yes    ┌───────────────┐
 │ majorityYes(stateVotes)? ├─────────▶│  SAFE_COMMIT  │
 └───────────┬──────────────┘          └───────────────┘
           no│
          ▼
        ABORT

The priority order encodes a threat model: structural integrity failures are treated as more urgent than a lone dissenter, which is itself more urgent than "just delay," which is itself more urgent than counting votes. The escalation veto is notably stronger than typical Byzantine quorum protections — those usually require ⌊n/3⌋+1 dissenters to block an action, whereas here a single agent voting ESCALATE is sufficient to force human review, regardless of how many other agents voted YES.

Classical consensus protocols (Paxos, Raft, PBFT) are judged against two properties: safety (nothing bad happens — no two conflicting values are ever chosen) and liveness (something good eventually happens, given enough correct, live nodes). vortexVote.js does not model liveness at all — there is no retry, timeout, or leader-election notion anywhere in the module. Its "safety" is really just deterministic evaluation of an already-collected, already-trusted snapshot of votes: it assumes the vote arrays are honest, with no Byzantine fault tolerance. A maliciously constructed {vote: "accept"} object is indistinguishable from a genuine one at this layer.

The honest characterization, consistent with the module's own header comment, is that vortexVote.js is a business-rule threshold engine borrowing consensus vocabulary — well suited to gating deploy pipelines, config changes, or human-review triggers, and not a substitute for a protocol offering formal distributed-systems guarantees.

1. GAP 01
   Fast Path threshold is not arity-relative fixed

   Resolved: the commit threshold is now computed as Math.ceil(stabilizers.length * (1/3)) against the actual validated array, not a hardcoded literal.

2. GAP 02
   Cyclic audit is not independent per round fixed

   Resolved: runCyclicAudit now accepts an optional pollFn(round, validators). Supplying one gives each of the 9 rounds a genuinely independent snapshot, so passes can land anywhere in [0,9]. Without a pollFn, behavior remains deterministic — this was an additive fix, not a breaking change.

3. GAP 03
   Slow Path guard ordering is implicit documented

   Resolved: the priority order (gates → escalation → entropy → majority) is now stated explicitly in the module's own header comment as a design decision, not left to be inferred from control flow.

4. GAP 04
   No Byzantine fault tolerance at the vote-object layer by design

   Out of scope for this module by design, and correctly disclosed in the header comment — but worth re-stating at every call site that feeds this module: it validates vote shape, not vote authenticity.

5. GAP 05
   Malformed input indistinguishable from a legitimate ABORT fixed

   Resolved (post-whitepaper addition): every path now validates input shape, arity, and enum membership at the boundary and returns Err(VortexVoteError) on failure — a distinct channel from the Ok({ outcome: ABORT, ... }) a caller gets from a legitimate quorum or vote-count failure. See §7 for the updated model.

§1's formal model is updated in the release to reflect a stricter contract:

P : V₁ × V₂ × ... × Vₖ  →  Result<Decision, VortexVoteError>

Result<T,E>  =  Ok(T)  |  Err(E)
Decision     =  { outcome: Outcome, details: object }

The distinction that matters: Ok({ outcome: ABORT, ... }) is a legitimate business result — the votes were well-formed and a quorum genuinely wasn't reached. Err(VortexVoteError) is a caller error — malformed shape, wrong arity, or an unrecognized enum value. GAP 05 (§6) was exactly this conflation in the pre-release version; the two channels are now structurally distinct, so a consuming system can retry/alert differently for each.

The module's own vocabulary — "no phase locks," "no silent failure," "fail fast," "total function" — borrows from several distinct bodies of literature: software error-handling patterns, distributed-systems fault models, and (once, loosely) electrical engineering. This section cross-checks each borrowed term against its source definition and states plainly which ones the code actually earns, which are deliberate departures, and which don't apply at all. Recording a negative result here is treated as equally load-bearing as a positive one — the same standard §6 already applies to the module's own claims.

8.1 Patterns the module genuinely implements

8.2 Concepts confirmed absent

These were checked against the source and are simply not present — consistent with, not contradicting, the liveness disclaimer already made in §5 (no retry, timeout, or leader election anywhere in the module).

8.3 "Phase lock" is a naming metaphor, not a claim

The module header's "NO PHASE LOCKS" principle (and the README's identical language) describes the absence of shared mutable state and cross-call ordering requirements — a software-engineering property. It is not a technical reference to phase-locking, the phase-locked loop, injection locking, or the lock-in amplifier — the electrical-engineering concepts the term is borrowed from. None of this module's functions have an oscillator, a frequency reference, or a signal-synchronization property. Consistent with how the project's "vortex math" (3-6-9) framing is already disclosed as metaphor rather than mechanism (Abstract, §5), no literal EE claim should be read into this naming.

8.4 Implementation footnotes

• Hash table — validateStateVotes checks membership via VALID_VOTE_STATES = new Set(Object.values(VoteState)), giving average-case O(1) lookups instead of an O(n) array scan. The set is fixed at 7 short string keys, so hash collision behavior is cited here only to rule it out as a concern, not because it is one — there is no attacker-controlled key space at this layer.
• Language surface — the implementation uses standard arrow-function callbacks (.filter, .some, .every; see also JS syntax — arrow functions) and ordinary if/for control flow — no exotic or version-specific language features anywhere in the module.

8.5 Explicitly out of scope — not force-fit

The following were considered and don't describe anything this module does. They're recorded so the absence reads as a checked decision, not an oversight.

• Proxy pattern — not used. Enum immutability (Outcome, VoteState, VotePath, ErrorCode) is Object.freeze, a direct mutation lock — not a Proxy-based interception layer.
• Web worker / shared memory / Spectre — this module has no browser or worker execution context, no SharedArrayBuffer, and no cross-thread shared mutable state. The "no shared mutable state" property already claimed (design notes, §1) is a purity and testability guarantee about ordinary synchronous JS call semantics — it is not a claim about immunity to speculative-execution timing side-channels, which is a distinct, hardware-level concern this module has no surface area for one way or the other.

A.1 Exported API

A.2 Fast Path — Reference Source

export function fastPath(primaryVotes, stabilizerVotes) {
  const primaryCheck = validateVoteArray(primaryVotes, 3, "primaryVotes");
  if (isErr(primaryCheck)) return primaryCheck;

  const stabilizerCheck = validateVoteArray(stabilizerVotes, 4, "stabilizerVotes");
  if (isErr(stabilizerCheck)) return stabilizerCheck;

  const primary = takeFirst(primaryCheck.value, 3);
  if (!hasQuorum(primary, 3)) {
    return Ok({ outcome: Outcome.ABORT, details: { reason: "no primary quorum" } });
  }

  const stabilizers = takeFirst(stabilizerCheck.value, 4);
  const acceptCount = countAccepts(stabilizers);
  // threshold scales with actual arity — fixes GAP 01
  const threshold = Math.ceil(stabilizers.length * (1 / 3));

  return acceptCount >= threshold
    ? Ok({ outcome: Outcome.COMMIT, details: { acceptCount, threshold } })
    : Ok({ outcome: Outcome.ROLLBACK, details: { acceptCount, threshold } });
}

A.3 Slow Path — Reference Source

export function slowPath({ stateVotes, gateChecks, entropyBufferTriggered = false }) {
  const gateCheckResult = validateGateArray(gateChecks);
  if (isErr(gateCheckResult)) return gateCheckResult;

  const stateVoteResult = validateStateVotes(stateVotes);
  if (isErr(stateVoteResult)) return stateVoteResult;

  // ── ordered guard chain — gates → escalation → entropy → majority ──
  if (!allGatesClear(gateCheckResult.value)) {
    return Ok({ outcome: Outcome.HOLD, details: { reason: "structural gates not clear" } });
  }
  if (stateVoteResult.value.some((s) => s === VoteState.ESCALATE)) {
    return Ok({ outcome: Outcome.HUMAN_REVIEW, details: { reason: "escalate vote present" } });
  }
  if (entropyBufferTriggered) {
    return Ok({ outcome: Outcome.DELAY_AND_AUDIT, details: { reason: "entropy buffer triggered ('?')" } });
  }
  if (majorityYes(stateVoteResult.value)) {
    return Ok({ outcome: Outcome.SAFE_COMMIT, details: {} });
  }
  return Ok({ outcome: Outcome.ABORT, details: { reason: "no majority yes" } });
}