Read candidate operations and the missing transport boundary

Why this matters

An agent can plan using capability requirements before hardware access exists.

Planning metadata must not inherit permission or proof of native protocol support.

Step by step

1. 01

   Select the capability category

   Screen or control: Driver operations

   Why: Operation count is definition coverage, not tested-driver coverage.

   How: Open Driver operations in P2. Select Describe a thermal-cycle request.

   What you should see: The definition has operationClass proposeThermalCycle, a candidate GDTI and a no-tested-transport boundary.

   Verify: Record #/P2/mhsSilaDriver/operations/2 and do not relabel this as Start run.

2. 02

   Inspect its declared inputs and output

   Screen or control: Download this source record

   Why: A request requires context and approval evidence, not just an operation name.

   How: Download the operation and read inputs, outputs, componentRoles, transportBoundary and executionAuthorized.

   What you should see: Inputs include Reaction layout and Approved profile required; the output is a Thermal-cycle request draft.

   Verify: There is no measured amplification curve, command receipt or native endpoint in this record.

3. 03

   Compare export and inspection definitions

   Screen or control: Describe a result export · Describe temperature / lid checks

   Why: Different capability purposes must keep separate identities and evidence requirements.

   How: Inspect these two operation records and download either one. Compare their operationClass, inputs and outputs.

   What you should see: A result-export description is distinct from required sensor/interlock evidence.

   Verify: Do not count required sensor evidence as sensors responding or a result package definition as actual measured results.

4. 04

   Read the driver-wide boundary

   Screen or control: MHS / SiLA capability model banner

   Why: A library-wide missing transport affects every proposed hardware operation.

   How: Scroll to the driver banner and read Native SiLA support and transportBoundary. Check the public package driver fields.

   What you should see: Native support is not asserted; driverHardwareState is unknown; no physical dispatch has been supplied.

   Verify: Write a transport-readiness checklist instead of attempting a hardware call or claiming a connected driver.

What is happening under the surface

The library contains six authored operation descriptions. Their state is candidate_non_executable.

An operation’s GDTI identifies its definition; inputs/outputs describe required context, not a live request/response trace.

No native or adapter transport, endpoint, credentials or hardware test is supplied; executable and executionAuthorized are false.

Common mistakes

• Never infer native SiLA support from a capability label.
• Do not rename a request draft as an executed experiment.
• A test plan, generated driver document and successful hardware test are different milestones.

The records an agent needs

These are read-only definitions for design review. A real executable driver needs an evidenced interface, bound endpoint, adapter/native implementation, qualified tests and scoped authorization. None is established by selecting a record.

Pointers locate records; hashes pin bytes; lesson numbers locate teaching material. None substitutes for an applicable assigned GS1 identity.

Apply what you learned

Draft a non-executable capability review for one operation.

Prepare these outputs

• Exact definition ID, source pointer, input/output list and referenced component roles.
• Explicit missing endpoint, adapter, credentials, acceptance tests and authority.
• A safe next step limited to evidence collection and review.

Review your work against these checks

• The review makes no hardware-dispatch claim.
• Transport and authorization gates remain separate.
• All original operation definitions remain unchanged.

Source and current boundaries

Screen basis: the anonymous public educational fixture at /api/demo/pillars, namespace 0614141. No private company record is read by this course.

Pinned assessed package SHA-256: b06ee255d0943a048511092595db4b98281b9b761d1910d19e6c3dba82591d94. Its complete graph contains 329 nodes and 231 directed relationships; original excluded assertions remain separately retained provenance. Lesson locators are educational numbers, not issued GS1 keys.

Scope: fictional authored records, non-issued identity proposals, unknown authority, no physical command, assay validation, cloud deployment or execution authorization.

Reading, answering a question and opening a diagram do not issue identifiers, validate a scientific method, establish company authority, commission an environment or authorize physical action.