GuardLaticeNATIVE LAB
Modules
WORKSPACEBraidCell
Documentation
BRAIDCELL

An agreement you can follow.

Finalize a value. Block a conflict. Recover the same witness.

4 local signers · quorum 3
MECHANISM PREVIEW
Illustrated mechanism · execute to see returned native events.
THE SCENARIO

A value becomes final.

Follow the proposal, signed votes and matching certificates.

Ready to execute the local C3 protocol.

Execution details & proof

Four synthetic local signers, unit weights, quorum 3. These are local native C3 calls. Animation is a reading aid; its pace is not execution latency. Fixture digests do not execute DA, MathGuard or C2RDT. Reload does not qualify process-crash or multi-host recovery.

Downloadable binary records bind returned events and public artifacts. Their checksum verifies byte integrity; independent cryptographic attestation and production admission remain outside this Lab.

Explore the source architecture
BRAIDCELL / THE EXACT WITNESS

Follow the mechanism.

Six source artifacts, from proposal to local apply. This diagram is a source study; returned native events appear in the execution panel above.

Drag to orbit · Scroll to zoom · Select an object

Select an object to read its role. Camera controls activate when the interactive viewer is available.

FOUR PHASES · ONE WITNESS PATHIllustrative choreography · timing is not a performance measure
01 / 06
SOURCE STUDY · NOT LIVE TELEMETRY

Proposal

Bind the proposed value to its native context.

Context + value
  1. Proposal

    Bind chain, epoch, height, round, registry and checkpoint to the proposed value.

    Context + value
  2. Lock votes

    Verify lock votes against the expected context and validator registry weights.

    Signed context
  3. LockQC

    Assemble the weighted certificate; retain the digest of its exact certificate body.

    Exact witness
  4. Commit votes

    Verify that witness and persist the matching local lock before returning a commit vote.

    Persisted lock
  5. CommitQC

    Verify the commit certificate against the supplied proposal and exact LockQC witness.

    Witness binding
  6. Local apply

    Require the durable matching lock, persist the next state, then advance memory and clear the completed lock.

    Persist then advance

Illustrated source order · schematic participants · reading pace is not execution latency, quorum or distributed consensus proof.

01 / 06
BraidCell — inspect a native lock and commit mechanismIllustration of selected NQFC-C3 mechanisms: a proposal is bound to context; validator lock votes assemble a weighted LockQC; commit votes bind that exact witness; verified certificates and a matching durable local lock allow a local state advance. Drawn participants do not specify the validator count or quorum threshold.PROPOSALLOCK VOTESLOCK QCCOMMIT VOTESCOMMIT QCV1 / LOCKV2 / LOCKV3 / LOCKV4 / LOCKV1 / COMMITV2 / COMMITV3 / COMMITV4 / COMMITVALUECONTEXTLOCKQCCOMMITQCLOCAL STATEWEIGHTED QUORUMEXACT LOCK WITNESSVERIFY CERTIFICATES + MATCH DURABLE LOCK → ADVANCECHAIN · EPOCH · PARENTEXACT CERTIFICATE-BODY WITNESSBraidCell native mechanism: proposal, lock votes, LockQC, commit votes, CommitQC and local stateVALUECONTEXTLOCKQCCOMMITQCVALIDATOR LOCK VOTESVALIDATOR COMMIT VOTESWEIGHTEDQUORUMEXACT LOCKWITNESSLOCAL STATECommitQC binds the exact supplied LockQC certificate-body witness
PER-NODE PERSISTENCEBefore a vote is returned; before memory advances.
  1. Signed slot

    Lock vote: persist the signed slot before returning.

  2. Commit lock + slot

    Commit vote: persist the value/witness lock and signed slot before returning.

  3. Next local state

    Apply: verify and match the lock, persist next state, then replace memory.

Selected dependencyDashed line: exact LockQC witnessParticipants are schematic; registry weights determine quorum.

Selected C3 caller dependencies · source study, not live validator events. Reading pace is independent of execution latency. Certificate verification, local persistence and distributed consensus are distinct boundaries.

Original four-phase links & no-script controls
SELECTED NATIVE CALLERS

Inside the execution.

Inspect a component and its actual caller dependencies. GLAP measures six server call windows; BraidCell / C3 shows selected source relationships.

SIX LAB OBSERVATION BOUNDARIES · NESTED RUNTIME CALLSWaiting for a request
Selected glap caller architectureSession and source bindingEncoded native packetActual native outcomeReplay scenario onlyExact packet resubmissionComplete private namespaceOpen owned journalRuntime admission and action resolutionOptional executor boundarySession & sourceGlapRootBindingAwaiting a real requestPacket encoderRoot-bound request v2Awaiting a real requestNative runtimeGlapNativeBackend<16,16>Awaiting a real requestSame-packet replaySame runtime + same bytesAwaiting a real requestResponse verifierGlapNativePacketOutcomeAwaiting a real requestOwned cleanupCompleted private slotAwaiting a real requestAdmission & catalogBounds · replay · auth · rootSource relationshipLocal journalPrivate run stateSource relationshipExecutor boundaryGL-T / GL-DDBS: NoneSource relationship
Selected caller dependencyMeasured Lab windowLayout represents software callers, not deployed nodes.

Select a component or use the component picker below.

COMPONENT / CALLER CONTRACT

Caller contracts and source identity
  1. Session & sourceGlapRootBinding

    The Lab acquires its private slot, creates random session material, obtains the current source binding and opens the local native journal. Measured together at the Lab caller boundary.

  2. Packet encoderRoot-bound request v2

    The real action, verb, session, nonce and source binding are encoded into the native request packet. The displayed byte count comes from this buffer.

  3. Native runtimeGlapNativeBackend<16,16>

    The existing handle_root_bound_v2 caller receives the actual packet and PublicReadOnly profile. Admission, authentication, catalog lookup and dispatch are inside this measured call; their individual durations are not observed.

  4. Same-packet replaySame runtime + same bytes

    Only the replay scenario calls the same native runtime a second time with the exact same packet. Other scenarios display Not called, never a fabricated zero-duration invocation.

  5. Response verifierGlapNativePacketOutcome

    The Lab checks the expected native class/error and zero effects, then encodes, authenticates, decodes and compares the actual response fields. It reports the digest and exact response bytes.

  6. Owned cleanupCompleted private slot

    After dropping the runtime, the Lab validates and removes only its completed synthetic journal files and slot. Failed namespaces remain preserved.

  7. Admission & catalogBounds · replay · auth · root

    The selected runtime caller invokes admit_packet_with_body_validator, resolves the action and checks source/catalog binding. This is source architecture inside one runtime call, with no separate live stage events.

  8. Local journalPrivate run state

    The selected run owns a local journal and replay bookkeeping. This is a bounded isolated Lab namespace, not a customer database or a remote validator node.

  9. Executor boundaryGL-T / GL-DDBS: None

    This Lab passes None for observed trust, trust admission and GL-DDBS executor arguments. Customer data writers, operator Health and consensus-network telemetry are not connected by these requests.

Selected source SHA-256: 12d5f0dde2c4ea2454fba7c9d30a70b6857986cb888ea9825926ac82db101bff. The Lab calls the retained native binary; this graph is not an inventory of every deployment component.

DURABLE LOCAL CONSENSUS CALLERS · SOURCE PROJECTIONLive C3 events not connected
Selected c3 caller architectureVerified proposalLock phase votesExact LockQC witnessCommit phase votesCommitQC and supplied LockQCPersist local lock before vote returnPersist signed slotPersist next state before memory updateRegistry/checkpoint signature dependencyRegistry and signing dependencySeparate checked round transitionProposalNqfcC3ProposalNot connected to live eventsLock voteNqfcC3PhaseVoteNot connected to live eventsLockQCPhase certificate + witnessNot connected to live eventsCommit voteDurable matching lockNot connected to live eventsRegistry & cryptoWeights · signaturesNot connected to live eventsPersist transitionNode state publicationNot connected to live eventsLocal applyLock check → persist → memoryNot connected to live eventsCommitQCExact LockQC witness bindingNot connected to live eventsTimeout pathSeparate round transitionNot connected to live events
Selected caller dependencyMeasured Lab windowLayout represents software callers, not deployed nodes.

Select a component or use the component picker below.

COMPONENT / CALLER CONTRACT

Caller contracts and source identity
  1. ProposalNqfcC3Proposal

    issue_nqfc_c3_proposal binds the chain, epoch, height, round, registry, checkpoint and value. The registry and signed checkpoint dependencies are separate inputs.

  2. Lock voteNqfcC3PhaseVote

    sign_nqfc_c3_lock_vote_durable verifies proposal/state/registry, derives the Lock context and delegates to issue_phase_vote_durable. A signed slot is persisted before returning the vote.

  3. LockQCPhase certificate + witness

    assemble_nqfc_c3_lock_certificate aggregates verified votes. The exact certificate-body digest is distinct from the certified context digest.

  4. Commit voteDurable matching lock

    sign_nqfc_c3_commit_vote_durable verifies the supplied LockQC, carries its exact witness, records the local lock and persists the signing transition before returning.

  5. Registry & cryptoWeights · signatures

    Registry binding, phase vote verification and checkpoint signing/verification are actual dependencies of these callers. Drawn nodes do not denote a real validator population.

  6. Persist transitionNode state publication

    issue_phase_vote_durable and local apply both call persist_state_transition. Local memory is replaced after the durable operation returns successfully.

  7. Local applyLock check → persist → memory

    apply_nqfc_c3_commit_certificate_durable verifies proposal and both certificates, requires the matching durable local lock, prepares the next height, persists it, then updates memory and clears the completed lock.

  8. CommitQCExact LockQC witness binding

    assemble_nqfc_c3_commit_certificate verifies the supplied LockQC and builds the Commit context with that exact justification witness. Local application remains a separate operation.

  9. Timeout pathSeparate round transition

    Timeout voting, certificate assembly and application have their own checked path. A successful diagram traversal does not establish distributed safety, liveness or recovery.

Selected source SHA-256: bec98a1073f5dc1344bc9b72aeaacea3191da8a02f120217ea54219e98f0a5c2. No validator network, operator state or live C3 event stream is connected to this view.

ACTUAL NATIVE OUTCOME

Ready for a native request.

Choose a scenario. Its result and measured call windows appear here.

Awaiting a real request
SERVER CALL WINDOWNot observed
NATIVE PACKETNot observed
NATIVE RESPONSENot observed
RUNTIME INVOCATIONSNot observed

Measurements arrive after completion, not as a streamed inner-event feed.

MEASURED WINDOW / SIX BOUNDARIESLengths follow captured durations

Individual server observation · excludes browser/network delivery · select a window to inspect its caller.

  1. Session & sourceNot observed
  2. Packet encodingNot observed
  3. First runtime callNot observed
  4. Repeated runtime callNot observed
  5. Response verificationNot observed
  6. Owned cleanupNot observed
Session and observation identity
Session
Not observed
Server time
Not observed
Native response SHA-256
Not observed
Observation record SHA-256
Not observed

GLLOBS01/v1 records six measured Lab wrapper boundaries and binds the native response/session. Its exact bytes are downloadable from the native result. These are individual observations; benchmark comparisons stay in the study tab.

Context, results & evidence
CURRENT WORKSPACE

Component details

Run an admitted GLAP scenario to capture a native result.