Spherion Web Interface — Guided Examples
Three independent exercises: BAYES, REFINE and COLLAPSE.
Read the situation, enter the supplied data yourself, review them and authorize one execution. These fictional examples demonstrate Kernel operations; they are not engineering assessments.
Keep this guide open in one tab and the SWI form in another. Start with BAYES, then try the two resolution exercises.
Before you begin — input fields and execution
Select Decimal input. Use the decimal point as shown. Snapshot format is 1. Enter every field in each row, including zeros, and preserve the row order. The labels in the first column explain the exercise; do not enter them as zone IDs.
Each exercise starts from its own supplied snapshot. Complete one exercise at a time; do not expect the form to transfer results between operations. Editing inputs invalidates the previous review and consent. If an outcome is unknown, use the status lookup rather than automatically submitting again.
The six numeric fields are independent inputs. For these exercises, m0 is a synthetic mass, weight is the operation's stored weight, and alpha is a supplied concentration parameter. The zero values of m1, sumsq and mean are deliberate background values, not road measurements. Zone IDs identify nodes in the Kernel hierarchy, not kilometre markers or geographic coordinates.
Example 1 — BAYES: What does a new inspection change?
Situation and need
A road team is assessing one section before deciding whether to request a more detailed inspection. It considers three possible conditions: good, intermediate and deteriorated. Its initial weights are 0.60, 0.30 and 0.10.
A new inspection detects a wear signal. For this fictional exercise, the team has already specified that the probability of detecting this signal is 0.10 under the good-condition hypothesis, 0.50 under the intermediate hypothesis and 0.90 under the deteriorated hypothesis. These values are supplied assumptions; the SWI does not estimate them from an inspection report.
Your task
Update the three weights using this evidence. In this demonstration, the three distinct root zones serve as labels for hypotheses about the same road section, not three physical road sections. This is an explicit application convention.
Enter the snapshot
Select BAYES. Create three rows in this order:
| Hypothesis (label only) | zone_id | m0 | m1 | sumsq | mean | weight | alpha |
|---|---|---|---|---|---|---|---|
| Good | 0 | 1 | 0 | 0 | 0 | 0.60 | 1 |
| Intermediate | 274877906944 | 1 | 0 | 0 | 0 | 0.30 | 1 |
| Deteriorated | 549755813888 | 1 | 0 | 0 | 0 | 0.10 | 1 |
Set the parameters
Domain: Linear. Normalize: enabled.
In likelihoods, enter one value per line, in the same order as the rows, without blank lines:
0.10
0.50
0.90Prepare the review. Check all three IDs, all six fields per row, the likelihood order and normalization. Then provide consent and authorize one execution.
After your attempt: understand the result
On success, the weights should be approximately 0.20, 0.50 and 0.30, in that hypothesis order. The other five fields remain unchanged. The evidence reduces the good-condition weight and increases the other two. It does not establish the actual physical condition or prescribe maintenance.
The mathematical calculation is initial weight × likelihood, divided by the sum of those products. In the checked native run, the last binary64 weight was 0.30000000000000004; this is the represented numerical result, approximately 0.30.
Optional: try a variation
Create a new explicit candidate with the same snapshot and likelihoods 1, 1, 1. With normalization enabled, weights should remain approximately 0.60, 0.30 and 0.10: equally compatible evidence does not favour one hypothesis over another. This variation has not been executed as part of the three checked baseline exercises.
Example 2 — REFINE: Preparing a more detailed representation
Situation and need
A monitoring team currently represents a study domain with one active zone. It wants four finer child zones so that later work can distinguish conditions within the domain. No new measurements have arrived yet, and the team has no basis for favouring one child over another.
Your task
Refine the parent using the equal four-child policy. This prepares a finer representation; it does not discover local differences or create measurements. The correspondence between these abstract children and physical subregions would have to be defined separately for a real application.
Enter the snapshot
Select REFINE. Start with exactly one row:
| Label only | zone_id | m0 | m1 | sumsq | mean | weight | alpha |
|---|---|---|---|---|---|---|---|
| Parent domain | 0 | 1 | 0 | 0 | 0 | 1 | 4 |
Set the parameters
Policy: Default. In Parents, enter:
0No custom weights are needed. Prepare the review, verify the parent ID and policy, provide consent and authorize one execution.
After your attempt: understand the result
On success, the active parent is replaced by these four children:
| zone_id | m0 | m1 | sumsq | mean | weight | alpha |
|---|---|---|---|---|---|---|
| 4294967296 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| 4294967297 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| 4294967298 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| 4294967299 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
The representation has finer resolution. Equal allocation expresses the selected policy, not evidence that the physical subregions are identical. The alpha value 4 was deliberately supplied so that each child receives 1 in this exercise.
Optional: try a variation
For a separate candidate, select Weighted and supply child weights 0.5, 0.25, 0.125 and 0.125 in child order 0–3. These exactly representable binary64 values sum to one. They encode a chosen allocation, not newly observed information. This variation has not been executed as part of the three checked baseline exercises.
Example 3 — COLLAPSE: Returning to a coarser representation
Situation and need
A monitoring team holds a four-child representation of one domain. For its next processing stage, it needs a single parent representation instead of four active child entries. This exercise uses equal synthetic child states so the reconstruction is easy to inspect.
Your task
Reconstruct the parent from its four active children using the default combination policy. Begin from the table below independently, even if you have already completed REFINE.
Enter the snapshot
Select COLLAPSE. Enter exactly these four rows in this order. Do not also enter the parent as an active row.
| Label only | zone_id | m0 | m1 | sumsq | mean | weight | alpha |
|---|---|---|---|---|---|---|---|
| Child 0 | 4294967296 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| Child 1 | 4294967297 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| Child 2 | 4294967298 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
| Child 3 | 4294967299 | 0.25 | 0 | 0 | 0 | 0.25 | 1 |
Set the parameters
Policy: Default. In Parents, enter the ID of the parent to reconstruct:
0Prepare the review. Check that all four children are present and that 0 appears only as the parent parameter. Provide consent and authorize one execution.
After your attempt: understand the result
On success, the four active child entries are replaced by one parent:
| zone_id | m0 | m1 | sumsq | mean | weight | alpha |
|---|---|---|---|---|---|---|
| 0 | 1 | 0 | 0 | 0 | 1 | 4 |
This gives a coarser state for subsequent work. The equality with the REFINE example's starting values holds for these selected inputs. It is not a general guarantee that REFINE followed by COLLAPSE restores every original state exactly. The collapsed state no longer carries the four separate active child entries.
Optional: try a variation
In a new candidate, remove one child row and request the same collapse. The four-child reconstruction requirement is no longer met; expect a collapse rejection rather than an automatically completed child set. A returned unchanged snapshot on rejection is not a successful collapse. This variation has not been executed as part of the three checked baseline exercises.