Proving how private input affects native RISC-V execution.

A verifier may need confidence that a native program consumed a genuine external input and that the input caused the machine behaviour being attested, while the input and sensitive intermediate state remain private.

That is more specific than proving that a program has some valid execution. The chain must connect origin, consumption, program-derived state, authenticated behaviour and verifier policy.

The Phase 1R.3B foundation closes a narrower subproblem: binding a selective zero-knowledge branch witness to the scalar actually observed at an authenticated RISC-V function entry. Its recorded canonical and adversarial sessions belong to that scope.

The result is useful because it identifies what the proof must bind at the execution boundary; it is not a shortcut to a claim about every native program or every monitor.

A successful proof is not enough if the evidence files leak the protected input, hidden registers or blinding values. The system therefore treats privacy audit, session custody, challenge freshness and public leakage as explicit properties.

This makes the verifier's view part of the protocol design instead of an afterthought added after the cryptographic relation is written.

The planned direction is private causal native-execution attestation: connect authenticated input provenance to a conservative data-dependence slice and then to verifier-interpreted machine behaviour without re-proving an entire native execution in a generic zero-knowledge VM.

That is a research hypothesis with open novelty, security and execution obligations. The page records the foundation and its limits rather than presenting the future chain as finished.