User
The user supplies intent, authority, preference, boundary, and final meaning. Without user alignment, an action becomes drift.
Purpose
A witness is not another controller. It is the alignment point.
The Shadow Witness Protocol is an informational architecture for checking whether a system is acting in accordance with the person operating it, the machine carrying the action, and the software transforming the command. It is designed as a practical governance layer for processors, agents, tools, interfaces, and long-running automation.
Instead of asking whether software can do something, the protocol asks whether the action is coherent across all three bodies: the user who authorizes, the hardware that constrains, and the software that interprets.
Model
The 3 → 2 → 1 → 0 loop
The system begins with three inputs, compresses them into two agreement checks, emits one decision, then resets any unstable state back to zero. The loop repeats without assuming that the next decision inherits authority from the last one.
3WitnessUser / Hardware / Software
2AgreeIntent ↔ Constraint
1DecideCommit / Hold / Reject
0ResetGame over, repeat clean
Hardware
The hardware supplies physical limit, available resource, identity of the executing device, sensor reality, and failure boundary.
Software
The software supplies memory, transformation, routing, policy, code path, and the actual operational interpretation.
Bare-Metal Kernel
Minimal operating law
READ_USER_INTENT()
READ_HARDWARE_STATE()
READ_SOFTWARE_STATE()
A = COMPARE(user, hardware)
B = COMPARE(user, software)
C = COMPARE(hardware, software)
IF A && B && C:
COMMIT_DECISION()
ELSE:
HOLD_ACTION()
EXPLAIN_DRIFT()
RESET_VOLATILE_STATE()
LOOP()Protocol
The four decision states
All three bodies agree. The action can proceed with a witness record.
Alignment is incomplete. The action pauses and asks for clarification or more state.
The action conflicts with user authority, hardware capacity, software boundary, or safety constraints.
The loop clears temporary assumptions so the next decision starts from a clean witness frame.
Architecture
Informational stack
Interface LayerCaptures intent in plain language and explicit controls.
Witness LayerCompares user, hardware, and software state.
Kernel LayerEnforces commit, hold, reject, and reset.
Memory LayerStores only the record required to verify continuity.
Execution LayerPerforms actions after alignment is proven.
Why it matters
Software usually drifts because it lacks a hard center.
Most programs treat execution as a straight line: input arrives, logic transforms it, output appears. That works for simple tools, but it becomes fragile when the system has memory, external tools, autonomous steps, or multiple interpretations of user intent. The Shadow Witness Protocol adds a center point before action.
The center point does not replace the user. It does not invent authority. It does not pretend the machine is unlimited. It does not let software silently reinterpret the request. It asks the same question each cycle: are these three bodies still aligned?
That makes it useful as a design pattern for AI agents, embedded devices, robotics, personal computing environments, workflow automations, model governance, and hardware-backed identity systems.
Production Spec
Version 0.1 reference
NameShadow Witness Protocol
Ratio1:1:1
Loop3 → 2 → 1 → 0 → repeat
DecisionCommit / Hold / Reject / Reset
First AuthorDavid Wise
Artifact TypeInformational protocol page
First Author Record
David Wise
First Author: David Wise
Protocol: Shadow Witness Protocol — a 1:1:1 alignment architecture for user, hardware, and software.
Canonical phrase: One user. One machine. One program. One witnessed decision.