eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Design a Blockchain Pilot: Freeze the Gates Before Reading the Results

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Article BC098

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

A useful blockchain pilot should be capable of failing. Decide what evidence would stop expansion before seeing the demonstration, then apply the same rule when the results arrive. A fast interface and a favourable average cannot compensate for a mandatory requirement that remains unproved.

This lesson builds a prospective acceptance protocol for a fictional shared catalogue. It supplies the workload, six mandatory gates, a non-blockchain comparator and the final evidence packet. Your job is to decide whether the candidate may advance to the next bounded evaluation stage. The answer will turn on an independent export check, rather than the most attractive performance result.

All organisations, workloads, thresholds and results are invented. No real deployment, personal data collection, production attack, vendor commitment or financial transaction is involved. The exercise teaches decision design; its thresholds are not industry standards or recommended production settings.

Choose your reading route

In this guide

Read sections 1–3 to define the question and freeze the protocol. Sections 4–7 explain the tests and supplied results. Sections 8–10 show the decision, repair plan and limits of the comparator. Complete the exercise before reading its answers. For the broader reasoning framework, see How Assurance Cases Work.

Back to contents · Next section

1. Ask one bounded decision question

Three fictional catalogue teams need to agree which approved revision is current. They want retained evidence explaining who authorised each accepted change. A departing team must be able to inspect an exported record package without depending on the original provider’s live dashboard.

Candidate B uses a permissioned blockchain. Comparator D uses a conventional shared database with signed change records. Both are classroom implementations. Neither is presumed preferable merely because of its architecture label.

The decision is narrow: does B satisfy the predeclared gates for advancing to a larger, still controlled evaluation? Passing would not authorise production launch, establish legal compliance or prove that B is better than every alternative. Failing means that this version does not qualify for that next stage under this protocol.

The teams name an evaluator who is separate from the candidate’s demonstration operator. For the exercise, that evaluator receives complete, authentic test evidence and correctly performs the specified checks. This is a supplied premise. In a real evaluation, access, conflicts of interest and reproducibility would themselves need scrutiny.

Back to contents · Next section

2. Freeze the workload and endpoint

Protocol P1 defines 100 distinct, authorised catalogue requests with known starting state, expected effects, identifiers and application rules. Both systems receive the same logical workload from independently reset fixtures. There is no connection between these records and real people or commercially valuable assets.

Each request’s timer begins when the complete request is admitted to the test interface. Completion requires successful application execution, the system’s documented durable-acceptance criterion and the evaluator’s observation of the expected resulting revision. For B, the supplied criterion includes its defined finality condition. For D, it includes its defined committed-record condition. These are declared implementation-specific evidence requirements, not an assertion that their failure models are identical.

A request counts toward the timely cohort only if all required evidence is observed within 60 seconds of its own start, inclusive. There is no substitution of submission acknowledgements for completion. Every request remains in the denominator of 100, including late or unresolved requests.

The controlled run holds the request mix, initial data, interface task and observation method fixed. It documents the versions and resource boundary. It does not reproduce all real operational conditions. One finite classroom workload cannot establish a universal throughput distribution or the behaviour of every future deployment.

Back to contents · Next section

3. Write six mandatory gates

Before results are opened, P1 records these six gates. Every gate must pass; there is no weighted average that can override a failure.

  1. Completion: at least 99 of the 100 ordinary requests meet the combined endpoint within 60 seconds each.
  2. Authorisation: all 20 separately specified unauthorised attempts leave the protected application state unchanged. Each uses an independent reset fixture.
  3. Recovery: after one specified node outage in the isolated test, service recovery takes no more than 120 seconds, with no divergent accepted results under the defined comparison check.
  4. Data placement: the designated synthetic contact sentinel is absent from every enumerated replicated input, event and state surface inspected by the protocol.
  5. Exit evidence: an independent evaluator reconstructs and validates the effects and authorisation evidence of all 100 eventually accepted ordinary requests from the exported package, without querying the original live provider.
  6. Resources: the specified complete test campaign uses no more than 12 kWh within its predeclared operational-equipment boundary.

The contact sentinel is a recognisable, deliberately fake test string, not a person’s contact information or a secret. Its test concerns a specified data placement requirement. The 12 kWh cap is a classroom resource limit, not an environmental certification threshold.

Back to contents · Next section

4. Make the tests produce inspectable evidence

Each ordinary request produces a start record, an endpoint observation and a link to the expected revision. The evaluator can account for all 100 identifiers. A missing endpoint does not vanish from the cohort; it remains late or unresolved at the cut-off.

The authorisation tests supply the attempted operation, the reason it lacks permission and the protected state before and after. The 20 attempts are distinct specified negative cases, not a complete search of every possible vulnerability. Resetting between them prevents an earlier mutation or revocation from silently changing a later case’s premise.

The recovery test deliberately affects only the isolated classroom system. Its start is the specified outage observation; its end is the first observation meeting P1’s restored-service predicate. The evaluator separately compares accepted results. Recovering within time while accepting conflicting results would fail the stated gate.

The data-placement test enumerates the inspected surfaces in advance. It is stronger than searching only the current user interface, but its conclusion remains limited to the chosen sentinel, surfaces and run. It cannot prove that all future personal data will be handled lawfully or that every possible external copy has been erased.

Back to contents · Next section

5. Define export success beyond row counting

Gate 5 requires more than downloading a file with 100 rows. The package must contain enough evidence for the independent evaluator to identify the initial state, applicable rule version, accepted sequence and authorisation supporting each effect. P1 defines these requirements before the supplier selects an export format.

For this fictional application, every accepted change requires a preserved approval record that the evaluator can authenticate and bind to that exact change. A complete current-state snapshot cannot replace the missing approval history. Nor can a provider’s “verified” label replace the independent check the gate explicitly requires.

This distinction has a useful technical parallel in Hyperledger Fabric’s ledger documentation, which separates current world state from transaction history. Our export gate is a bespoke application requirement; it is not a claim that Fabric supplies this exact package or that every blockchain uses Fabric’s data model.

The evaluator may use the supplied offline tools and documented trust material in P1, but cannot call the original live provider for missing answers. The requirement tests a bounded form of exit capability. It does not assert that an export can reproduce an entire network’s future operation or remove the need for every external trust assumption.

Back to contents · Next section

6. Open the candidate’s result packet

Candidate B produces these supplied observations:

  • Exactly 99 ordinary requests meet the endpoint within 60 seconds. The remaining request completes at 75 seconds. All 100 are eventually accepted with their expected application effects.
  • All 20 unauthorised attempts leave protected state unchanged in their independent fixtures.
  • The specified node outage recovers in 90 seconds. The defined comparison finds no divergent accepted results.
  • Complete inspection of the enumerated surfaces finds no designated synthetic contact sentinel.
  • The export contains all 100 accepted record rows and reproduces their current effects, but authentic, change-bound approval evidence is present for only 95. For five records, the evaluator cannot establish the required authorisation from the package.
  • The complete campaign’s defined operational-electricity total is 10 kWh, including the components specified in P1.

Treat these observations as correct for the exercise. Do not infer that the five changes were actually unauthorised: missing export evidence is not proof of historical misconduct. The failure is that the package cannot satisfy the independent verification requirement.

Also do not reinterpret the 75-second completion as a permanent failure. It is a late completion relative to the 60-second gate and remains one of the 100 eventually accepted records used by the export test.

Back to contents · Next section

7. Apply each gate without changing its wording

Gate 1 passes: 99/100 equals 99%, meeting the threshold exactly. The boundary is inclusive. A request completed at exactly 60 seconds would count; one completed after it would not.

Gate 2 passes for the 20 specified cases. Gate 3 passes because 90 is at most 120 and the separate consistency check also passes. Gate 4 passes for the sentinel and completely enumerated surfaces in this run.

Gate 5 fails: 95 independently verifiable approval records are fewer than the required 100. Having 100 rows and correct-looking current state does not satisfy the missing evidence condition. Gate 6 passes because 10 is at most 12 kWh within the supplied complete boundary.

The result is five passing gates and one failure. Writing “83.33% successful, therefore approved” would invent an aggregation rule absent from P1. The protocol requires all six. A mandatory exit requirement is not a small penalty to be traded against spare electricity capacity.

Back to contents · Next section

8. Write the decision and explain its consequence

The model decision is: “Do not advance candidate B version B1 under protocol P1. The candidate meets five mandatory gates, but its exported package does not permit the required independent authorisation validation for five of 100 accepted changes. Record the favourable results and retain the failed evidence for correction and retest.”

This conclusion is neither a rejection of blockchain in general nor a finding that the five changes were fraudulent. It is a decision about the supplied version and acceptance rule. Preserving that scope makes the report more useful to engineers and decision-makers.

The immediate next step is to identify why the required evidence is absent: was it never retained, omitted by export, inaccessible under the supplied trust material, or incorrectly bound to a change? The dossier does not answer that. Do not choose a cause simply because one would be easier to fix.

Until the cause and repair are verified, the previously agreed exit condition remains unmet. A demonstration operator showing the missing approvals on the original dashboard would not by itself repair a requirement for offline independent export validation.

Back to contents · Next section

9. Repair and retest without moving the goalposts

Suppose a revised candidate B2 is proposed. Keep B1’s result and P1’s original thresholds. Record the changed components, export schema, evidence-retention behaviour and verifier version before a new run. The new result should identify exactly which version it evaluates.

At minimum, reproduce the failed export scenario and any tests affected by the repair. If retaining extra approval evidence changes replicated data placement or electricity use, those gates need fresh evidence too. If application execution or authorisation code changes, their related tests cannot simply inherit B1’s pass without justification.

A fully repeated P1 campaign is one clear option for this small exercise. A narrower regression plan would require an explicit impact argument; it is not automatically sufficient because a developer calls the patch small.

Changing the requirement from 100 verifiable records to 95 after seeing B1 would be a new policy decision, not a retroactive pass under P1. Decision-makers may sometimes revise requirements for legitimate reasons, but should preserve the original failure, explain the change and assess its consequences. The exercise supplies no authority to waive this gate.

Back to contents · Next section

10. Use the comparator without overclaiming

Comparator D completes 98 of the same 100 ordinary requests within 60 seconds; the other two finish at 70 and 80 seconds. All 100 eventually complete correctly. Its export contains independently verifiable approval evidence for all 100 records. Other D gate results are not supplied.

B has one more timely completion in these runs. D has a complete export for this requirement. These observations do not establish a universal performance advantage or prove that blockchain caused the difference. They also do not authorise D automatically: it misses P1’s timely-completion threshold, and four of its other gate results are unknown.

If the project requires exactly these mandatory criteria, neither supplied result packet demonstrates an eligible candidate. That can be a productive outcome. The teams have learned what must improve without pretending that the most visually impressive demonstration is ready.

The Magenta Book emphasises planning evaluation early and matching evidence to the question. Here, the comparator is part of a prospective learning design. It does not transform a small technical acceptance run into a causal evaluation of all organisational benefits.

Back to contents · Next section

11. Exercise: decide before reading the answers

Answer these questions using P1 exactly as written.

  1. Does B’s 99% timely-completion result pass Gate 1?
  2. Can 100 exported rows pass Gate 5 when five required approval records cannot be validated?
  3. Does the export failure establish that five historical operations lacked authority?
  4. Can B’s 2 kWh margin below the resource cap compensate for the export failure?
  5. Is D approved because its export is complete?
  6. If B2 exports all evidence but places the synthetic contact sentinel into an enumerated event surface, may it advance?

Model answers: yes to question 1 because the threshold is inclusive. No to question 2: the gate requires evidence validation, not just row count. No to question 3: the historical facts remain unresolved by this package. No to question 4 because all gates are mandatory. No to question 5: D misses the timely gate and lacks evidence for other gates. No to question 6: B2 would fail the specified data-placement gate even if its export defect were repaired.

For a final writing task, produce a two-sentence decision note naming the candidate version, protocol version, failed requirement and bounded next action. A correct note should preserve successful tests without letting them erase the failure.

Back to contents · Next section

Frequently asked questions

Why not choose thresholds after learning what is realistic?

Exploration can help design a later acceptance protocol. Label it as exploration. Once P1 is the declared acceptance rule, changing it after results must be transparent and cannot silently rewrite the earlier outcome.

Does passing all six gates prove production readiness?

No. It would support advancement only within the stated next-stage decision. Real readiness can require broader security, governance, operational, accessibility and jurisdiction-specific review beyond this synthetic campaign.

Does a retained blockchain history guarantee a useful export?

No. A useful independent package also needs interpretable rules, identities, permissions, ordering context and the evidence required by the application. The exact requirements depend on the intended verification task.

Where should the reader continue?

Use Logistics Benchmarking for comparison discipline. Then consider how a proposed supplier obligation could specify the evidence and acceptance test, rather than promising only a dashboard feature.

Back to contents · Next section

Sources and further reading

A well-designed pilot preserves the right to say “this version has not yet demonstrated what we agreed to require.”

Back to contents