Modality::Ultrasonic has been registry code 7 since v0.1 with nothing implementing it. This is that implementation.

It replays .ultrasonic.jsonl recordings from BatVu — a handheld sonar that runs entirely in a phone browser: a 17.5–20.5 kHz chirp out of the speaker, a matched filter over the microphone, and a range profile of echo amplitude against distance along one beam.

One new module in rufield-adapters, its pub mod / pub use lines, a dev-dependency on rufield-privacy, a test fixture, and a README section. No other crate changes; the workspace manifest needs nothing.

The tensor is [Range], and that is an argument rather than a default

[Angle, Range] is the obvious shape for a sonar and it would be a lie here. FieldAxis::Angle means angle-of-arrival bins — the output of an array that has measured direction. BatVu has one microphone. The direction attached to an echo is where the operator happened to be pointing the phone, which is pose, not signal.

So the profile is rank-1 and the beam rides in SensorDescriptor::orientation_xyzw, as the minimal rotation taking sensor-local +Z onto it. Roll about the boresight is unobservable with one transducer pair, so the minimal rotation is the one that asserts nothing about the axis nobody measured.

Worth noting for the record: validate_evidence_at would have accepted any of the three candidate shapes. There is no Modality::Ultrasonic branch in rufield-core and this PR does not add one — the choice is enforced by the adapter's own tests instead.

Two output modes, and the safe one is the default

The full per-bin profile is a sensor frame, and RuField classifies the analogous per-subcarrier CSI frame P0. Calling ours something gentler would be special pleading for our own modality.

Max-pooling rather than averaging is deliberate: a mean smears a sharp echo into its neighbours and a wall stops looking like a wall, whereas a maximum keeps every peak the detector cared about and discards only the shape between them — which is precisely the part worth not transmitting.

the_stock_privacy_policy_lets_the_coarse_profile_onto_a_network_and_refuses_the_raw_one checks this with DefaultPrivacyGuard itself, rather than by reading the class off the struct and agreeing with ourselves.

max_privacy_class is set per mode and not as a .max() over what is emitted — PrivacyClass orders P0 < P5, so the raw mode's P0 is numerically the smallest while being the most sensitive, and a maximum would report P1 for it.

A recording cannot relabel itself into a higher trust tier

Every line declares its source, and the adapter is constructed with the source the deployment is willing to accept. A file claiming device_capture handed to an adapter configured for simulation is refused outright — and so is the reverse, so neither direction is a silent reinterpretation. provenance.synthetic is then derived from the accepted source rather than taken from a field the file controls.

The parser is hostile on purpose

Modelled on quantum_rf_replay, which is the more defensive of the two existing parsers:

• line length capped before serde_json sees the bytes, so an oversized line cannot allocate its way past the check
• deny_unknown_fields, so a stray key is a parse error rather than attacker-controlled CPU spent parsing and discarding
• bounded profile bins, detections and total pings
• finiteness and sign checked on every numeric — a NaN survives FieldTensor::validate (which checks only shape and axis rank), signs fine, verifies fine, and then fails to deserialize as an f32 on the far side of the wire, which is the worst place to find it
• strictly increasing timestamps, and a year-2100 clock bound. This one is not tidiness: TrustVerifier's watermark only ever advances, so a single event with a saturated clock permanently blocks every honest event from that device
• identifiers rejected for control characters and length; a recording that changes device_id midway rejected outright
• a detection lying outside the profile it came from refused as incoherent, rather than admitted into a fused map with no measurement behind it
• no trailing-line tolerance: every malformed line is a hard error with its line number

Each of these has a test that names the input it stops.

The honest negative result

The adapter sets features["range_m"] — the key the fusion window actually reads, as against the typed Observation::range_m field, which it also sets and which fusion never looks at.

It deliberately does not set features["presence"], although doing so would light up the shipped person_present rule and make a demo work. An echo at 2.4 m is a surface. One transducer pair cannot tell a person from a coat on the back of a chair, and a range-only sensor reporting presence is asserting exactly that distinction.

The consequence is that with the shipped room_state.toml, a BatVu scan produces no inferences at all — for two independent reasons, both pinned by the_shipped_rules_have_no_predicate_a_range_only_sensor_can_drive:

1. No rule lists "ultrasonic" among its inputs, so no rule ever sees the events.
2. Adding one would not help. The engine's feat vocabulary — motion_energy, breathing_band, transient, presence, posture_sit, posture_lie — is entirely statements about a body. range_m reaches the window but has no feat arm, and the only predicate that reads it (range_depart) additionally requires motion_energy > 0.4, which a phone standing still cannot supply.

The gap is in the rule vocabulary, not the adapter: RuField v0.1 has no predicate for static geometry. Closing it is a change to rufield-fusion and out of scope here.

observation.attributes["evidence_kind"] is set to synthetic_replay / captured_replay following quantum_rf_support.rs, because bearing_trust's simulation policy rejects a synthetic event whose evidence kind is <missing>. An ultrasonic event has no bearing to fuse and should never reach that engine, but "should never" is not a mechanism.

Cross-language conformance

tests/fixtures/batvu_living_room.ultrasonic.jsonl is not hand-written. It is generated by BatVu's own npm run artifacts from a 72-ping simulated sweep of its living-room scene, written by the TypeScript emitter in @batvu/field, and copied here verbatim. If BatVu's emitter and this parser ever drift apart, a build fails in one repository or the other rather than an ingest failing in a deployment.

tests/ultrasonic_fusion.rs drives that fixture through the whole stack: parse → calibrate → sign → validate_evidence_at → TrustVerifier → DefaultPrivacyGuard → RuFieldFusion::ingest.

Honesty

Every current BatVu recording is its own simulator's output. The events are therefore synthetic: true, and captured_replay() and production() reject them outright — as they should. The pipeline is real and the fixture is a real cross-language check; the measurements are not yet from a phone, and the README says so in both places it introduces the adapter.

Verification

• 32 unit tests + 7 integration tests, all passing
• cargo test --workspace green
• cargo fmt --all -- --check clean
• cargo clippy --workspace --all-targets -- -W clippy::all introduces no new warnings (the two too_many_arguments are pre-existing)

🤖 Generated with Claude Code

https://claude.ai/code/session_01BRtoJRh2M4LV3vLcSg2nSX

Generated by Claude Code