01
Signal provenance
Where did the observation originate, under what acquisition path and context?
Signal Attestation
Trust begins before the model.
A valid signature can establish that a statement was signed. Device attestation can establish identity and measured state. Neither fact alone establishes that the originating physical observation should have been trusted when the system acted.
Living Cipher starts farther upstream: source evidence → admission → authorized computation → provenance → verifier-facing receipt.
“
Cryptography can preserve the integrity of a statement without establishing the truth of the physical event the statement represents.
Signal-attestation boundary
Four Distinct Layers
Do not collapse source trust into machine trust.
The architecture keeps distinct claims separate so a downstream verifier can reason about what each layer actually establishes.
02
Signal evidence
What bounded evidence supports freshness, live-source coupling, deviation, or other source-veracity requirements?
03
Compute provenance
What authorized computation transformed the admitted observation and under which approved state?
04
Platform attestation
Which authorized device or system produced, bound, and released the result?
Public Architecture
Live source → evidence → admission → compute → receipt.
The public interface exposes the architectural contract and observable behavior. Proprietary witness construction, scoring, thresholds, dependence modeling, tamper-decision logic, and private implementation topology remain protected.
01
Live Source
Biological or physical signal enters through a defined acquisition context.
02
Witness Evidence
Bounded source evidence is derived without exposing private construction.
03
Context Binding
Session, freshness, device context, and policy-relevant state are associated.
04
Admission
The system decides whether the observation may influence consequential compute.
05
Authorized Compute
Approved resources act on admitted input under governed state.
06
Receipt
The verifier receives evidence connected to source, context, and computation.
Current Demonstrator
Change the conditions. Observe the receipt change.
The Signal Witness demo is a software prototype using live voice-channel input. It demonstrates the public behavioral proposition: altered conditions can change witness state and therefore the resulting receipt.
Current maturity: software witness and receipt generation are live. PolarFire SoC integration is in progress; the hardware-rooted receipt path is next.
Prior characterization: 1.6M voice-channel captures exercised. Session-local counters in the demo represent the current browser session and should be read separately from prior characterization.
From Signal to Heterogeneous Compute
The source problem and the chiplet problem are the same architectural question at different boundaries.
A relying party needs evidence about what is entering the computer and evidence about what is allowed to participate in producing the result. Signal attestation and component enrollment therefore meet in the same trust plane.
Beyond Silicon
Source evidence remains relevant when the computational substrate changes.
Biological, quantum, neuromorphic, and hybrid systems may accept inputs, maintain state, and produce outputs in ways that do not map neatly onto today's secure-boot and digital-attestation assumptions. The architectural requirement remains: establish what participated, what evidence connects the physical event to the computation, and what the relying party is actually entitled to believe.
This is a research direction. Current product and implementation work remains anchored in FPGA, SoC, chiplet, and future ASIC hardware.