Example
Worked example / Organization
Moving cart, checkout, and support onto one allocation function
A cart preview, checkout, and a support replacement all need the same answer: how many units can this order claim? The first implementation works, but two workflows carry private copies of a policy that already has a name.
The logic is written in Bosatsu, a typed functional language. Yichus compiles that source before it reports definitions and dependencies; the diagrams below come from the compiled program.
01 / Application requirement
Calculate allocations consistently at each customer touchpoint.
The component receives a stock snapshot with on-hand, already committed, and safety-stock quantities. It must clamp invalid negative quantities to zero, subtract committed and safety stock, and allocate no more than the normalized request. Every result reports requested, allocated, backordered, and remaining sellable units.
The channel wrappers deliberately differ. The allocation itself is the shared business rule.
02 / The maintenance problem
The policy exists, but only checkout calls it.
Cart and support were delivered around the same time. Each workflow
computes an Allocation inside its own function, while checkout
calls allocation_plan. A change to safety stock or backorder
handling now has three places to reach.
Featured WebMCP request:
api_abstraction_map({ sources: [{ fileName: "before.bosatsu", source: "…complete source…" }] })
Complete before source · Exact map request · Exact map response · Organization response
The recorded map shows compiled user definitions and their direct
dependencies. Follow the arrows from the three entry points. Checkout
reaches allocation_plan; cart and support reach
min_int, nonnegative, and
sellable_units themselves.
Recorded engine result · before
Two workflows route around the policy block.
Loading recorded evidence…
Select a definition to read its direct dependencies.
All map measurements
Exact request, response, and complete source
Request
Response
Complete program
03 / The repair
Make each channel depend on the allocation plan.
The repair removes the two embedded calculations. Cart and support now
obtain an Allocation from the same definition as checkout;
their channel-specific result types and status decisions stay in place.
Focused source diff
def cart_preview(sku: String, stock: Stock, requested: Int) -> CartPreview: - allocation = Allocation( - nonnegative(requested), - min_int(nonnegative(requested), sellable_units(stock)), - nonnegative(requested).sub(min_int(nonnegative(requested), sellable_units(stock))), - sellable_units(stock).sub(min_int(nonnegative(requested), sellable_units(stock))), - ) + allocation = allocation_plan(stock, requested) CartPreview(sku, allocation, is_complete(allocation)) def support_replacement(case_id: String, stock: Stock, requested: Int) -> SupportReplacement: - allocation = Allocation( - nonnegative(requested), - min_int(nonnegative(requested), sellable_units(stock)), - nonnegative(requested).sub(min_int(nonnegative(requested), sellable_units(stock))), - sellable_units(stock).sub(min_int(nonnegative(requested), sellable_units(stock))), - ) + allocation = allocation_plan(stock, requested)
Complete focused diff · Complete repaired source · Exact repaired map request · Exact repaired map response
Recorded engine result · after
The three entry points meet at one policy.
Loading recorded evidence…
Select a definition to read its direct dependencies.
All map measurements
Exact request, response, and complete source
Request
Response
Complete repaired program
The repaired organization result reports no allocation bypass. The map
also shows a new direct edge from each workflow to
allocation_plan. These results establish the compiled
dependency shape; they do not prove that the policy itself matches a
warehouse contract.
Read the repaired organization request and response
04 / Behavior check
Exercise ordinary orders and inventory boundaries.
The recorder executed cart, checkout, and support in both complete programs over a named scenario set. Each returned allocation was compared with the written rule, and each complete channel result was compared before and after. The set includes an ordinary full allocation, a partial allocation, overcommitted stock, invalid negative inputs, the exact safety boundary, and a zero request.
| Scenario | Stock snapshot | Request | Allocation | Comparison |
|---|
Exact run requests, responses, and all scenario records
Representative partial-allocation run · before
Representative partial-allocation run · after
Complete bounded scenario record
These executions pin the chosen cases. They do not quantify over every
Bosatsu Int, and the organization lens does not claim behavioral
equivalence.
05 / Run and change it
Use the same source and browser engine.
Open the drawer to switch between both complete versions, run the partial cart scenario, change the stock inputs, rebuild the map, edit a copy, or reset. Compiler and runtime results appear in the drawer.
Code & run Inspect both complete order-allocation programs
Recording identity
Loading recording identity…
Desktop verification capture · Phone verification capture
Replay the recorder and verify the committed evidence with:
YICHUS_ENGINE_REVISION=<bundle-build-revision> YICHUS_SOURCE_REVISION=<source-checkout-revision> YICHUS_APIMCP_BUNDLE=<path-to-main.js> node scripts/record-order-allocation-example.mjs --check
Where this fits
What this is about: Lenses and Diagrams