01 / THE ROLE
In this lab.
The application host includes Floci components and a separate web UI component. It is used as an experimentation surface for cloud-compatible service interactions. The UI is dynamic and may be absent or stopped without that automatically constituting a production incident.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Experiment client
- STEP 02Local service emulator
- STEP 03Experiment state
- STEP 04Result or UI
03 / How it works
How it works.
A local emulator allows a client or application to exercise selected service interactions without treating the emulator as a real cloud account. Compatibility and supported behaviours must be established for the specific experiment; the presence of an AWS-style UI is not proof of complete cloud equivalence.
04 / Persistent data & recovery
Persistent data & recovery.
Decide whether the experiment contains unique state or whether it can be recreated from test definitions. The UI container and emulator can have different storage requirements. Real cloud credentials are unnecessary for a neutral public example and must never be embedded in the documentation.
05 / How to check it
How to check it.
Validate the exact operation the experiment relies on, including expected create/read/delete behaviour where safe. A frontend page response only proves that interface is served. Do not assume the source deployment method of a dynamically created component has been fully documented.
06 / Decisions & limits
Decisions & limits.
On-demand tooling needs a different availability expectation from an operational service. Keeping that classification explicit avoids generating incidents for intentional experiment lifecycles.