How to use this knowledge base

Start with what you're trying to understand or fix. Follow the links to the relevant specification and product documentation, and check which parts apply to your equipment.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Does not replace normative standards, product manuals, or site specific engineering.

Verification and testing

Overview#

Use the library to build a mental model and a verification checklist. Do not copy a generic design into a live site.

Begin with the integration question#

Write the outcome before choosing technology. For example: “deliver a camera tamper observation to a case management system within 15 seconds, without losing the source timestamp or creating a control path back to the camera.” That statement exposes the actors, data, timeliness, trust direction, failure tolerance, and safety boundary.

Then follow this sequence:

1. Identify the systems in system architecture.
2. Mark every network, administrative, physical, and supplier trust boundary.
3. Classify each interface using architecture and layering.
4. Establish the canonical entity, state, event, command, and timestamp meanings using events, state, commands, and time.
5. Read the relevant protocol page and its exact version/lifecycle notes.
6. Check the product's official documentation, supported firmware/software, conformance declaration, security advisories, and licensing terms.
7. Record assumptions and unresolved gaps before implementation.

Check the scope and evidence#

The front matter describes the page's usable scope. Pay particular attention to:

• content_status: whether the page is maintained, draft, historical, or a pointer;
• technology_status: current, release candidate, legacy, deprecated, historical, or mixed;
• verification: what evidence review occurred;
• runtime_status: execution evidence state for executable material;
• coverage_limit: what the page deliberately doesn't claim;
• last_verified and next_review: whether mutable facts may be stale.

A high verification state can't widen a narrow coverage_limit. A V2 page about public documentation doesn't validate an undocumented endpoint or every device bearing a vendor name.

Know what kind of claim you are reading#

Words such as must, shall, should, and may are lowercase advisory prose unless a page attributes them to a normative source. Don't silently convert one source's recommendation into a protocol requirement.

Use examples safely#

Examples use reserved names, documentation networks, synthetic identifiers, and clearly marked secret placeholders. Runtime metadata uses these states:

• conceptual: illustrates a relationship, not executable syntax;
• protocol-fragment: intentionally incomplete wire or payload excerpt;
• not-executed: a complete code/protocol example without linked environment evidence;
• partially-runtime-validated: only the linked cases and environment have recorded evidence;
• runtime-validated: the exact stated claim has a complete linked validation record.

No example should be treated as production ready merely because it parses. Validate authorisation, version compatibility, timeouts, bounds, certificate handling, logging, rollback, and physical consequences.

For an authorised isolated check or deployment acceptance activity, use the environment validation checklist and keep the evidence narrowly scoped.

When sources disagree#

Prefer the applicable normative edition, then official corrigenda/errata, conformance material, and current product documentation. Record the conflict rather than averaging it away. A deployed legacy device may correctly implement an older edition; “newer” and “applicable” aren't always the same.

See the source policy, verification policy, and known gaps.

Section overview · Wiki home