Pilot design
Write the pass condition before the first enrollment.
A small evaluation should settle one real question. A private build tool, client preview or provider allowlist is a better first scope than every device and route in the organisation.
Can an approved engineer reach the private build dashboard?
One supported laptop · one owned server · one access group
Permitted access works; an unapproved identity has no grant
Temporary membership is removed and observed state is checked
Illustrative pilot brief. This does not submit an application or establish availability.
Run a useful evaluation
Baseline, enable, verify, remove.
Baseline
Record the existing application, listener, platform and ordinary network behaviour. Choose a non-critical first resource.
Enable the smallest boundary
Confirm product, platform and market readiness, then authorise only the path needed to answer the question.
Verify both sides
Observe the allowed connection and a relevant negative test. Record the resource’s apply state alongside the application result.
Remove and hand over
Withdraw temporary access or publication, inspect the result and leave the operating owner a clear record.
Plan an evaluation
Agree on the setup, the owner and the outcome.
A pilot should establish whether a specific connection works safely in the intended environment. It should be small enough that its outcome and removal can be observed clearly.
Define the pilot question
Write the resource, owner and intended connection in one sentence. For example, an approved engineer needs one private build host, or an integration worker needs a provider-observed outgoing identity. A portfolio-wide demonstration is not a substitute for that question.
Prepare the assessment brief
| Decision | Information to bring |
|---|---|
| Ownership | Workspace administrator and resource/network owner |
| Outcome | Product, audience, direction, protocol and traffic scope |
| Environment | Platform/version, local network and existing constraints |
| Eligibility | Intended market and assessed product/release support |
| Success | Allowed and unapproved paths, application result and observations |
| Closure | Removal authority, restoration and allocation disposition |
Keep production assumptions out of the first test
Choose a non-critical target and controlled change window. Do not assume HA, a response SLA, global infrastructure or future product support. Customer terms, data practices and actual release readiness require separate review.
Observe both connection and removal
Test the permitted result and the boundary that should remain closed. Inspect local apply state rather than treating a requested policy as success. Withdraw the relevant grant or rule and verify removal/restoration before deciding to expand.
Contact Fibmesh to discuss the scope, timing and requirements of a pilot. A conversation does not reserve capacity or confirm acceptance. Use the resource plans and availability to prepare your brief.
Discuss a pilot →