Emergent behaviour, system-of-systems and integrated evidence

A component result has assumptions

System-level properties arise through arrangements and interactions among elements. Emergent behaviour can be useful or harmful; the term does not mean that behaviour is magical or impossible to explain. Follow resource competition, information delay, control rules, physical coupling and people’s responses to understand how a combined outcome occurs.

A component test often assumes particular inputs, loads or environmental conditions. Combining components can change those conditions. An independently adequate power unit, display and processor might create a different thermal or timing problem when enclosed together. Identify which assumptions remain valid and which integrated observations or models are needed rather than extending every local result without checking.

A retry example exposes a multiplicative path

Our original idealised model begins with 10 requests. Each client issues 3 attempts, so the station receives 30. Suppose the station forwards each received attempt as 2 backend attempts. Under the stated rules, the backend receives 60 attempts. The example assumes every attempt propagates, without an early successful stop or duplicate suppression.

This calculation does not predict a particular network. It identifies a coupling worth examining: retry rules at two boundaries can multiply work and alter delay. Message identity, timing, completion state and resource limits affect the real outcome. A nominal single-request test cannot establish performance when many requests or retries coincide.

Integrated services can cross independent ownership

A system of systems combines constituent systems with their own operational purposes and management. In a library service, catalogue, building network and regional reservation service may continue operating and evolving under different owners. Calling them one service does not grant the station team authority to change all of them.

Maintain agreed interfaces, ownership, applicable versions and notification of consequential changes. Assemble evidence at the relevant levels: a supported component, a compatible interface, an integrated task and operational observations each answer part of the claim. Record gaps and the conditions under which a conclusion holds. When usage or another constituent changes, reassess affected assumptions and observations instead of assuming the original integration remains representative indefinitely.

A count does not reveal who waits for the work

Extend the simple attempt bound with a separate constructed loaded case. One catalogue backend executes jobs in first-come, first-served order, one at a time, without pre-emption. Every actual job takes 180 ms. Network transit and processing of retry metadata are set to zero for this model. It is not the earlier R1 normal-connected case or its 50 ms allocation. All events use one controlled clock, and no other work is initially present.

A client sends logical lookup K at time 0 and retries once at 150 ms unless it already has a reply. A naive station creates a separate context for each received attempt. Each context forwards a backend job immediately and retries once after 100 ms unless its own first backend job has completed. Work already queued is not cancelled. Backend K arrivals are therefore at 0, 100, 150 and 250 ms: the first completion at 180 closes the original context, but the context created at 150 is still waiting when its timer fires at 250. Completing one logical lookup has not erased its sibling context.

An independent caller’s non-retrying probe J arrives at 200 ms. The resulting execution order is K0 from 0–180, K100 from 180–360, K150 from 360–540, J from 540–720 and K250 from 720–900. J’s backend turnaround is 720−200=520 ms. The four K jobs consume 720 ms of backend work even though the first useful K result exists at 180. This finite event trace explains a cross-caller delay; it does not establish instability or a failure probability for a real service.

A compatible message can still mean a different request

In a coordinated variant, the station keeps one pending state keyed by caller plus logical_request_id. K’s client repeat at 150 joins that state instead of creating another context. Its single backend retry at 100 carries the same logical ID. Crucially, the catalogue coalesces repeated logical K before admitting work to its queue. A duplicate does not create another execution. The result at 180 satisfies the waiting callers and cancels the logical timer. Then only K executes at 0–180 and J at 200–380, so J’s turnaround is 180 ms.

Coalescing queued computation is an explicit additional agreement. Merely promising that repeating an operation has the same final effect does not prove that repeated requests consume no work. Distinguish a logical request ID, reused for attempts at one intent, from an attempt ID that identifies each transmission. Separate users intentionally making identical lookups can still have distinct logical requests; do not infer intent just from equal parameters.

Now an independently managed catalogue C2 retains valid message fields but changes its coalescing key to attempt_id. The station still coalesces the client repeat, yet its backend retry at 100 has a distinct attempt ID and enters the queue. K0 runs 0–180, K100 180–360, and J 360–540: J now takes 340 ms. Syntactic compatibility did not preserve the assumption behind the earlier performance result. Retain C1 evidence with its configuration, invalidate its applicability to C2 for this claim, and have the catalogue and station owners reconcile identity semantics before repeating the integration case.

Keep constituent evidence and the remaining system gap visible

Use a bounded claim: in this two-caller workload, J’s backend turnaround is at most 200 ms. The coordinated model predicts 180 ms and the naive model 520, but a model prediction is not an observed integration result. The table identifies what each owner would have to supply. A successful station-only test with a perfect stub cannot show whether the independent catalogue actually coalesces before its queue.

Even a measured backend 180 ms would not establish a broader 200 ms end-to-end visitor response. Only 20 ms would remain for omitted transit and station handling, whose values have not been supplied. Record that specific mismatch instead of upgrading a backend result into a whole-service pass. Separately, lookup identity and queue evidence say nothing about whether an interrupted physical collection was confirmed. The earlier distinction between READY and confirmed collection still applies.

This is how lifecycle evidence becomes usable: name the claim, conditions, configurations, owners and observation; identify which assumption a constituent change invalidates; and preserve what still applies. Here a change of catalogue key invalidates one-execution-per-logical-K evidence and the dependent J turnaround prediction. It need not erase the unrelated physical display observation. The next observation should resolve the causal gap, rather than simply collect another successful nominal response.

Distinguish counts from a performance claim

The constructed attempt ratio is 60/10=6 backend attempts per original request. If a changed station rule allowed only one backend attempt for each of the 30 client attempts, the same simplified account would give 30. That is a reduction in the counted work under these assumptions, not evidence of an acceptable response time or overall service availability.

A useful investigation would connect the configured rules to event records and representative load conditions, including which operation each message concerns. Check whether completed work is recognised consistently and whether delayed responses cause further actions. Preserve the identity and timing relationships needed to explain the interaction, with appropriate handling of any real users’ information.

For the explicit FIFO case, sort backend arrivals by time, then start each job at the later of its arrival and the preceding completion. With naive K arrivals 0,100,150,250 and J arrival200, the start times are 0,180,360,540,720 ms in arrival order K0,K100,K150,J,K250. J finishes 720 and takes 520 ms. With coalescing before queue admission only K0 and J remain, starting 0 and 200 and finishing 180 and 380; J takes 180 ms. The difference comes from work admitted ahead of J, not from a changed J service time.

Try the reasoning

1. Does a component passing a local load test establish performance after integration?

   Show the answer and reasoning

   Only within assumptions that remain applicable. Shared resources and interactions can change the relevant conditions.

2. What distinguishes a system of systems in this lesson?

   Show the answer and reasoning

   Constituent systems retain operational purposes and management while contributing to a combined capability.

3. Does halving the constructed attempt count prove the service meets its timing requirement?

   Show the answer and reasoning

   No. Counts, timing, completion behaviour and intended service outcomes require related but distinct evidence.

4. In the naive model, change only the station retry delay to 200 ms while the client still retries at 150. Does this remove duplicate work or make J meet its 200 ms backend bound?

   Show the answer and reasoning

   No. K0 executes 0–180 and cancels the original context’s timer at 200. The client-created K150 executes 180–360. Its own retry fires at 350 before that context’s first job completes at 360, so K350 remains queued. J arrived at 200 ms and executes 360–540 before K350, giving 340 ms turnaround, above 200. There are three actual K jobs. Changing one timeout without tracing separate contexts is insufficient.

5. The station test passes against catalogue C1, but C2 coalesces by attempt ID while message fields still parse. Which old conclusion is no longer applicable, and what observation should be requested?

   Show the answer and reasoning

   The one-execution-per-logical-K assumption and its dependent 180 ms J prediction are not established for C2. Capture logical and attempt IDs alongside actual queue admissions/start/completion records for the changed configuration. With the supplied model, K0,K100,J execute 0–180, 180–360, 360–540, giving 340 ms for J. Both owners must agree on identity semantics; another parsed nominal reply alone cannot resolve the mismatch.

6. Keep perfect logical coalescing but increase actual job service time to 220 ms. What happens to J arriving at 200, and why does one K execution not settle performance?

   Show the answer and reasoning

   K occupies 0–220. J waits 20 ms, runs 220–440 and has turnaround 440−200=240 ms, exceeding the 200 ms backend condition. Suppressing duplicate work reduces load but does not bound the service time of remaining work. The capacity/timing evidence must match the changed constituent; a count of one K execution is not a timing pass.

What to carry forward

Follow interactions and ownership across the complete service, and keep integrated claims tied to the assumptions and evidence that actually support them.