What the evidence can tell you

Glassknock makes ordinary requests to one supplied endpoint. It receives media during a bounded sample and sends H.264 data to a local FFmpeg process for decoding. It keeps measured results rather than images or recordings.

Evidence boundaries

Evidence	Useful conclusion	Conclusion it cannot support
Supplied TCP connection opens.	This computer connected to the supplied address and port.	The service is a camera, or every camera is reachable, powered, or secure.
Video access succeeds.	This request was allowed.	All accounts or paths work.
A frame decodes.	The received data produced readable video.	Good night vision, detection coverage, or recording.
Reception passes a sample.	The completed sample met its delivery rule.	Daily uptime or simultaneous capacity for many feeds.
Repeat test passes a prior finding.	That measured condition improved at this viewpoint.	The whole installation is repaired.

Data

The configuration contains the endpoint and a local label. Review it before sharing; it is not a sanitized report.
Credentials are supplied separately through explicitly selected terminal or standard input. They are used for the run and omitted from reports and process arguments.
The local label, run metadata, correlation fingerprint, and measured evidence appear in reports. Choose a label suitable for sharing. A fingerprint is not a guarantee of anonymity.
Device-provided text and camera URLs are not included in agent output. Treat any information obtained separately from equipment as untrusted data.
The tool receives video but saves no frame or recording. It does not send diagnostics to Rimward or an AI service.
If an agent reads a report, its provider can receive that report. The agent’s permissions are separate from Glassknock’s fixed diagnostic behavior.

Validation levels

Automated fixtures can verify software behavior. They cannot establish hardware compatibility.

Level	Evidence required	Claim allowed
Build	Successful build for an operating system/architecture.	“Builds for this target.”
Fixture	Reproducible local protocol and video tests.	“This behavior passed these software tests.”
Hardware	Model, firmware, endpoint type, codec, runner, settings, and results.	“This exact setup was tested.”
User trial	Another person completes installation, diagnosis, and repeat test.	“This workflow was completed in this trial.”

The automated suite exercises actual H.264 decoding, trusted and untrusted RTSPS, connection/access failures, interrupted reception, time bounds, missing dependencies, cancellation, secret removal, and comparison rules. See the PR validation record for tested environments and results.

Hardware and independent installer or agent-host trials remain unverified. Protocol fixtures and cross-compilation do not establish brand-wide support. Copying a skill file does not prove that an agent discovers or follows it.

Record a real equipment test

For a real-equipment trial, use this checklist. Report only the exact setup tested:

Item	Example format
Equipment	Exact model and firmware; direct camera or recorder channel.
Feed	H.264; main or secondary feed; credentials required or not. Do not publish a secret URL.
Runner	Operating system, architecture, Glassknock version, FFmpeg version, and network viewpoint.
Test	Requested duration, timeout, gap threshold, and actual duration.
Result	Sanitized report, successful behavior, and unresolved failures.

Do not upload a camera configuration, credential source, image, or video by default. Review any extra support material locally before submission.

To contribute code, install Go 1.26.6 or newer and FFmpeg 5.1 or newer, then run:

go build ./cmd/glassknock
go test ./...
go vet ./...

Keep measurement rules explicit and results qualified. A new codec, transport, or repair action needs tests for its real behavior and an updated scope statement.

When runtime dependencies change, update THIRD_PARTY_NOTICES.md to match go list -m all. Keep the exact upstream license and copyright text for each dependency.