TheRON/otivm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

initial upload

Browse Source
This commit is contained in:
TheRON
2026-04-30 15:13:20 -04:00
parent b3ce30d8cf
commit 241aef5687
3 changed files with 1080 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

381
docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0011-round-trip-cart-value.chunked.md Normal file
View File

@@ -0,0 +1,381 @@
# CORPUS-0011
## Round-Trip Cart Value
### Status: Training Corpus Seed
### Layer: Layer_1--Worked_Examples
### Purpose: Teach that transport capacity may create value in both directions, and that a route should not always be evaluated as a one-way movement
### Repository Path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0011-round-trip-cart-value.md
---
<!-- chunk:
id: CORPUS-0011::01::calculation
source_file: CORPUS-0011-round-trip-cart-value.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0011-round-trip-cart-value.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0011
document_title: Round-Trip Cart Value
section_heading: 0. Scenario + 1. One-Way Assumption + 2. Known Facts ...
chunk_role: calculation
concept_tags:
- round
- trip
- cart
- value
- calculation
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader in Ostia wants to send goods to Capua.
A cart from Capua has already arrived in Ostia carrying raw material.
The cart must return to Capua.
If the trader can load the return trip, the cart owner avoids travelling empty, and the trader may obtain better terms.
The same physical journey can carry value in both directions.
---
## 1. One-Way Assumption
A weak model may treat transport as a simple one-way purchase:
```text
Ostia -> Capua cart hire = 10 asses
```
If the trader must pay the whole hire, the cost may erase profit.
But if the cart already needs to return to Capua, the trader may only need to pay for unused return capacity.
The cart's prior movement matters.
---
## 2. Known Facts
| Fact | Value |
|---|---:|
| Cart origin | Capua |
| Cart current location | Ostia |
| Cart must return to Capua | yes |
| Normal one-way hire Ostia -> Capua | 10 asses |
| Reduced return-leg rate | 5 asses |
| Trader's cargo value in Ostia | 20 asses |
| Expected sale value in Capua | 32 asses |
| Other handling costs | 3 asses |
---
## 3. One-Way Calculation
If the trader pays full one-way hire:
```text
purchase value: 20 asses
cart hire: 10 asses
other handling: 3 asses
------------------------------
total cost: 33 asses
sale value: 32 asses
result: 1 as loss
```
The venture fails by arithmetic.
---
## 4. Return-Leg Calculation
If the trader uses the cart's required return trip:
```text
purchase value: 20 asses
return-leg rate: 5 asses
other handling: 3 asses
------------------------------
total cost: 28 asses
sale value: 32 asses
result: 4 asses profit
```
The same cargo and destination become viable because transport capacity was already moving.
---
## 5. Why The Cart Owner Accepts
The cart owner may accept the reduced return-leg rate because:
- the cart must return to Capua anyway
- empty return earns nothing
- the load offsets animal feed and driver time
- the trader pays promptly
- the trader may offer repeat business
- the cargo is easy to handle
The reduced rate is not generosity.
It is shared use of existing movement.
---
<!-- /chunk -->
---
<!-- chunk:
id: CORPUS-0011::02::risk_variant
source_file: CORPUS-0011-round-trip-cart-value.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0011-round-trip-cart-value.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0011
document_title: Round-Trip Cart Value
section_heading: 0. Scenario + 1. One-Way Assumption + 6. Round-Trip Exchange Variant
...
chunk_role: risk_variant
concept_tags:
- round
- trip
- cart
- value
- risk_variant
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader in Ostia wants to send goods to Capua.
A cart from Capua has already arrived in Ostia carrying raw material.
The cart must return to Capua.
If the trader can load the return trip, the cart owner avoids travelling empty, and the trader may obtain better terms.
The same physical journey can carry value in both directions.
---
## 1. One-Way Assumption
A weak model may treat transport as a simple one-way purchase:
```text
Ostia -> Capua cart hire = 10 asses
```
If the trader must pay the whole hire, the cost may erase profit.
But if the cart already needs to return to Capua, the trader may only need to pay for unused return capacity.
The cart's prior movement matters.
---
## 6. Round-Trip Exchange Variant
The arrangement may include value in both directions:
### Capua -> Ostia
The cart brings:
- raw timber
- wool
- charcoal
- agricultural goods
- workshop material
### Ostia -> Capua
The cart returns with:
- oil
- imported goods
- tools
- household supplies
- finished stock
- letters or documents
Each leg may serve a different party.
The trader may profit not by owning the cart, but by understanding that the cart should not return empty.
---
## 7. Household Supply Variant
The return cargo may not all be market cargo.
A Capua cart owner may ask to carry supplies for his household:
- oil
- fish sauce
- cloth
- tools
- small luxury items
- medicines or prepared goods
These goods may partly settle the transport agreement.
This creates a mixed exchange:
```text
cash payment
+ goods carried for household use
+ future hauling preference
```
The model should not treat household supply as irrelevant.
It can be part of the transport bargain.
---
## 8. Risks Of Linked Legs
A round-trip arrangement can fail because either leg fails.
Risk examples:
- inbound cargo arrives late
- cart needs repair before return
- animals are tired
- driver changes terms after arrival
- outbound cargo is not ready
- return cargo is heavier than expected
- goods for household use are disputed in value
- delay on first leg destroys profit on second leg
A round-trip plan may reduce cost, but it increases dependency between events.
---
<!-- /chunk -->
---
<!-- chunk:
id: CORPUS-0011::03::success_condition
source_file: CORPUS-0011-round-trip-cart-value.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0011-round-trip-cart-value.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0011
document_title: Round-Trip Cart Value
section_heading: 0. Scenario + 1. One-Way Assumption + 9. Correct Model Behavior ...
chunk_role: success_condition
concept_tags:
- round
- trip
- cart
- value
- success_condition
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader in Ostia wants to send goods to Capua.
A cart from Capua has already arrived in Ostia carrying raw material.
The cart must return to Capua.
If the trader can load the return trip, the cart owner avoids travelling empty, and the trader may obtain better terms.
The same physical journey can carry value in both directions.
---
## 1. One-Way Assumption
A weak model may treat transport as a simple one-way purchase:
```text
Ostia -> Capua cart hire = 10 asses
```
If the trader must pay the whole hire, the cost may erase profit.
But if the cart already needs to return to Capua, the trader may only need to pay for unused return capacity.
The cart's prior movement matters.
---
## 9. Correct Model Behavior
The model should ask:
- does the cart need to return anyway?
- is return capacity empty?
- who controls the cart?
- what did the cart carry inbound?
- what can it carry outbound?
- does return cargo reduce effective transport cost?
- are cash, goods, and future obligations combined?
- what risks link the two legs?
Transport is not only a price.
It is moving capacity across time and direction.
---
## 10. Incorrect Model Behavior
The model should not:
- treat every cart hire as isolated one-way cost
- ignore why the cart is already in Ostia
- ignore empty return capacity
- ignore household supply as value
- assume reduced rate is unexplained discount
- ignore linked-leg risk
- calculate each leg without considering the whole movement
---
## 11. Layer-0 Concepts Used
This example uses:
- `CORPUS-0001-trade-requires-two-locations`
- `CORPUS-0004-cost-includes-more-than-purchase-price`
- `CORPUS-0005-profit-is-sale-minus-total-cost`
- `CORPUS-0006-delay-is-economic-cost`
- `CORPUS-0009-liquidity-differs-from-wealth`
- `CORPUS-0013-non-coin-settlement-exists`
- `CORPUS-0018-rivalry-changes-conditions`
---
## 12. Success Condition
If the model sees a cart moving between two cities and asks whether both directions can carry value before calculating transport cost, this file is functioning correctly.
<!-- /chunk -->
---

366
docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0012-reputation-loss-changes-future-arithmetic.chunked.md Normal file
View File

@@ -0,0 +1,366 @@
# CORPUS-0012
## Reputation Loss Changes Future Arithmetic
### Status: Training Corpus Seed
### Layer: Layer_1--Worked_Examples
### Purpose: Teach that reputation loss does not rewrite the settled account of a completed venture, but can change the costs, access, and margins of future ventures
### Repository Path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0012-reputation-loss-changes-future-arithmetic.md
---
<!-- chunk:
id: CORPUS-0012::01::calculation
source_file: CORPUS-0012-reputation-loss-changes-future-arithmetic.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0012-reputation-loss-changes-future-arithmetic.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0012
document_title: Reputation Loss Changes Future Arithmetic
section_heading: 0. Scenario + 1. Completed Venture Arithmetic + 2. Reputation Damage
...
chunk_role: calculation
concept_tags:
- reputation
- loss
- changes
- future
- arithmetic
- calculation
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader sends oil from Ostia to Capua.
The venture produces coin profit.
However, the trader delivers late and handles the buyer poorly.
The completed venture remains profitable by arithmetic.
But reputation loss changes the conditions of future ventures.
---
## 1. Completed Venture Arithmetic
| Item | Value |
|---|---:|
| Sale value in Capua | 24 asses |
| Purchase price in Ostia | 10 asses |
| Movement and handling | 6 asses |
| Storage and incidental cost | 2 asses |
Total cost:
```text
10 + 6 + 2 = 18 asses
```
Immediate result:
```text
24 - 18 = 6 asses profit
```
The venture made 6 asses.
Reputation loss does not change that settled arithmetic.
---
## 2. Reputation Damage
The buyer expected delivery sooner.
The trader arrived late and blamed others instead of settling the matter cleanly.
The buyer paid, but now trusts the trader less.
Possible effects:
- buyer demands a lower price next time
- buyer refuses advance agreement
- seller hears of late delivery
- cart driver asks for coin upfront
- warehouse keeper stops extending easy terms
- information from Capua becomes slower or less reliable
The immediate venture remains profitable.
The next venture becomes harder.
---
## 3. Future Venture Before Reputation Loss
Before reputation damage, the trader expected:
| Item | Value |
|---|---:|
| Expected sale value | 24 asses |
| Purchase price | 10 asses |
| Transport cost | 6 asses |
| Other costs | 2 asses |
Expected result:
```text
24 - (10 + 6 + 2) = 6 asses profit
```
---
## 4. Future Venture After Reputation Loss
After reputation damage:
- buyer offers 22 asses instead of 24
- cart driver requires 2 extra asses upfront
- seller refuses delayed payment, reducing liquidity flexibility
New arithmetic:
| Item | Value |
|---|---:|
| Sale value | 22 asses |
| Purchase price | 10 asses |
| Transport cost | 8 asses |
| Other costs | 2 asses |
New result:
```text
22 - (10 + 8 + 2) = 2 asses profit
```
The same route still works, but margin falls from 6 asses to 2 asses.
Reputation loss became arithmetic through changed terms.
---
<!-- /chunk -->
---
<!-- chunk:
id: CORPUS-0012::02::risk_variant
source_file: CORPUS-0012-reputation-loss-changes-future-arithmetic.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0012-reputation-loss-changes-future-arithmetic.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0012
document_title: Reputation Loss Changes Future Arithmetic
section_heading: 0. Scenario + 1. Completed Venture Arithmetic + 5. Harder Variant
chunk_role: risk_variant
concept_tags:
- reputation
- loss
- changes
- future
- arithmetic
- risk_variant
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader sends oil from Ostia to Capua.
The venture produces coin profit.
However, the trader delivers late and handles the buyer poorly.
The completed venture remains profitable by arithmetic.
But reputation loss changes the conditions of future ventures.
---
## 1. Completed Venture Arithmetic
| Item | Value |
|---|---:|
| Sale value in Capua | 24 asses |
| Purchase price in Ostia | 10 asses |
| Movement and handling | 6 asses |
| Storage and incidental cost | 2 asses |
Total cost:
```text
10 + 6 + 2 = 18 asses
```
Immediate result:
```text
24 - 18 = 6 asses profit
```
The venture made 6 asses.
Reputation loss does not change that settled arithmetic.
---
## 5. Harder Variant
If reputation damage is worse:
| Item | Value |
|---|---:|
| Sale value | 21 asses |
| Purchase price | 10 asses |
| Transport cost | 9 asses |
| Other costs | 3 asses |
Result:
```text
21 - (10 + 9 + 3) = 1 as loss
```
A route that was once profitable now fails.
The physical route did not change.
The actor's social terms changed.
---
<!-- /chunk -->
---
<!-- chunk:
id: CORPUS-0012::03::success_condition
source_file: CORPUS-0012-reputation-loss-changes-future-arithmetic.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0012-reputation-loss-changes-future-arithmetic.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0012
document_title: Reputation Loss Changes Future Arithmetic
section_heading: 0. Scenario + 1. Completed Venture Arithmetic + 6. Correct Model
Behavior ...
chunk_role: success_condition
concept_tags:
- reputation
- loss
- changes
- future
- arithmetic
- success_condition
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader sends oil from Ostia to Capua.
The venture produces coin profit.
However, the trader delivers late and handles the buyer poorly.
The completed venture remains profitable by arithmetic.
But reputation loss changes the conditions of future ventures.
---
## 1. Completed Venture Arithmetic
| Item | Value |
|---|---:|
| Sale value in Capua | 24 asses |
| Purchase price in Ostia | 10 asses |
| Movement and handling | 6 asses |
| Storage and incidental cost | 2 asses |
Total cost:
```text
10 + 6 + 2 = 18 asses
```
Immediate result:
```text
24 - 18 = 6 asses profit
```
The venture made 6 asses.
Reputation loss does not change that settled arithmetic.
---
## 6. Correct Model Behavior
The model should separate:
| Category | Meaning |
|---|---|
| settled arithmetic | result of completed venture |
| reputation effect | change in trust, access, or terms |
| future arithmetic | later costs and sale values altered by reputation |
| access condition | whether actors will still transact |
| credit condition | whether delayed settlement remains available |
Reputation is not merely narrative flavor.
It changes future numbers.
---
## 7. Incorrect Model Behavior
The model should not:
- subtract reputation loss from a completed coin result without a defined mechanism
- rewrite a profitable settled venture as unprofitable after the fact
- ignore reputation because it is not coin
- treat future terms as unchanged after trust damage
- assume reputation effects are vague and non-economic
- ignore access loss, higher costs, or worse prices
---
## 8. Layer-0 Concepts Used
This example uses:
- `CORPUS-0005-profit-is-sale-minus-total-cost`
- `CORPUS-0006-delay-is-economic-cost`
- `CORPUS-0009-liquidity-differs-from-wealth`
- `CORPUS-0010-credit-depends-on-trust`
- `CORPUS-0011-status-changes-access`
- `CORPUS-0012-every-venture-risks-loss`
- `CORPUS-0019-success-has-no-boundary-failure-has-a-hard-stop`
- `CORPUS-0020-posture-changes-by-audience`
---
## 9. Success Condition
If the model keeps the completed venture's arithmetic fixed while allowing reputation loss to change future costs, access, credit, and margins, this file is functioning correctly.
<!-- /chunk -->
---

333
docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0013-festival-demand-and-after-event-bargains.chunked.md Normal file
View File

@@ -0,0 +1,333 @@
# CORPUS-0013
## Festival Demand And After-Event Bargains
### Status: Training Corpus Seed
### Layer: Layer_1--Worked_Examples
### Purpose: Teach that predictable gatherings can raise demand before an event and create discounted surplus after the event
### Repository Path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0013-festival-demand-and-after-event-bargains.md
---
<!-- chunk:
id: CORPUS-0013::01::calculation
source_file: CORPUS-0013-festival-demand-and-after-event-bargains.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0013-festival-demand-and-after-event-bargains.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0013
document_title: Festival Demand And After-Event Bargains
section_heading: 0. Scenario + 1. Before The Event + 2. During The Event ...
chunk_role: calculation
concept_tags:
- festival
- demand
- event
- bargains
- calculation
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader in Ostia learns that a festival or public gathering in Capua will increase demand for food, oil, cheap cloth, drink, lamps, and small comforts.
Before the event, sellers move goods toward Capua because buyers will gather there.
After the event, some sellers may be tired, short of coin, unwilling to pay storage, or eager to move on.
The same event can create two different opportunities:
1. selling into rising demand before the gathering
2. buying leftover stock after the gathering and moving it to the next place
---
## 1. Before The Event
Before the event, demand may rise for:
- food
- oil
- wine
- lamps
- cloth
- cheap ornaments
- animal feed
- lodging
- porterage
- temporary stalls
- repair work
A trader may send goods early to sell into higher demand.
Example:
```text
purchase value in Ostia = 20 asses
transport and handling = 6 asses
expected sale value in Capua before festival = 34 asses
expected result = 8 asses profit
```
The profit depends on arriving before the demand peak is satisfied.
---
## 2. During The Event
During the event:
- prices may rise for urgent goods
- porterage may become expensive
- lodging may tighten
- carts may be unavailable
- buyers may pay more for convenience
- sellers may run out of stock
- officials or local organizers may restrict certain spaces
The trader may profit if positioned early.
But late arrival can be costly.
---
## 3. After The Event
After the event, unsold goods may become discounted.
Sellers may want to avoid:
- storage cost
- return transport
- spoilage
- breakage
- fatigue
- tied-up capital
- missed next market
A trader with available coin, storage, or transport may buy leftover goods below ordinary value.
Example:
```text
leftover goods bought after event = 18 asses
handling and storage = 4 asses
transport to next location = 5 asses
expected sale value elsewhere = 34 asses
expected result = 7 asses profit
```
The bargain exists because the seller faces post-event pressure.
---
<!-- /chunk -->
---
<!-- chunk:
id: CORPUS-0013::02::success_condition
source_file: CORPUS-0013-festival-demand-and-after-event-bargains.md
repository_path: docs/training/corpus/Layer_1--Worked_Examples/CORPUS-0013-festival-demand-and-after-event-bargains.md
domain: commerce
layer: Layer_1--Worked_Examples
document_id: CORPUS-0013
document_title: Festival Demand And After-Event Bargains
section_heading: 0. Scenario + 1. Before The Event + 4. Incorrect Model Behavior ...
chunk_role: success_condition
concept_tags:
- festival
- demand
- event
- bargains
- success_condition
- worked_examples
knowledge_state:
- actor_visible
- settled_result
- designer_analysis
actors: []
-->
## 0. Scenario
A trader in Ostia learns that a festival or public gathering in Capua will increase demand for food, oil, cheap cloth, drink, lamps, and small comforts.
Before the event, sellers move goods toward Capua because buyers will gather there.
After the event, some sellers may be tired, short of coin, unwilling to pay storage, or eager to move on.
The same event can create two different opportunities:
1. selling into rising demand before the gathering
2. buying leftover stock after the gathering and moving it to the next place
---
## 1. Before The Event
Before the event, demand may rise for:
- food
- oil
- wine
- lamps
- cloth
- cheap ornaments
- animal feed
- lodging
- porterage
- temporary stalls
- repair work
A trader may send goods early to sell into higher demand.
Example:
```text
purchase value in Ostia = 20 asses
transport and handling = 6 asses
expected sale value in Capua before festival = 34 asses
expected result = 8 asses profit
```
The profit depends on arriving before the demand peak is satisfied.
---
## 4. Incorrect Model Behavior
The model should not:
- treat festival demand as random
- ignore predictable timing
- assume high demand lasts forever
- assume leftovers are worthless
- ignore post-event seller pressure
- ignore transport scarcity before the event
- ignore storage pressure after the event
- treat every after-event bargain as automatically safe
The event creates a cycle, not a single price change.
---
## 5. Correct Model Behavior
The model should separate:
| Stage | Market Condition |
|---|---|
| before event | rising demand, transport competition |
| during event | high urgency, crowded access, price volatility |
| after event | surplus, fatigue, storage pressure, discounted stock |
| next location | possible resale if demand remains unmet elsewhere |
The trader must identify where in the cycle he is acting.
---
## 6. Risk Variants
### Variant A — Arrives Early
The trader reaches Capua before the event.
```text
sale value = 34 asses
total cost = 26 asses
result = 8 asses profit
```
### Variant B — Arrives Late
Other sellers satisfy demand first.
```text
sale value = 27 asses
total cost = 26 asses
result = 1 as profit
```
### Variant C — Buys Leftovers Poorly
The trader buys leftover goods, but they are damaged or unsuitable for the next location.
```text
sale value = 24 asses
total cost = 27 asses
result = 3 asses loss
```
### Variant D — Buys Leftovers Well
The trader buys sound leftovers from tired sellers and moves them to another event location.
```text
sale value = 34 asses
total cost = 27 asses
result = 7 asses profit
```
---
## 7. Timing Questions
The trader must ask:
- when does the event begin?
- when does demand peak?
- when do sellers arrive?
- when do buyers depart?
- which goods spoil or lose value quickly?
- which goods remain useful after the event?
- is transport available after the crowd leaves?
- where is the next demand location?
The event calendar is an economic map.
---
## 8. Non-Coin Settlement Variant
After the event, a seller may accept mixed settlement:
- some coin now
- help moving goods
- storage for one night
- a share of resale
- goods exchanged for transport
- future priority at the next gathering
The trader should track obligations, not only coin.
---
## 9. Layer-0 And Layer-1 Concepts Used
This example uses:
- `Layer_0/CORPUS-0002-goods-have-local-prices`
- `Layer_0/CORPUS-0004-cost-includes-more-than-purchase-price`
- `Layer_0/CORPUS-0005-profit-is-sale-minus-total-cost`
- `Layer_0/CORPUS-0006-delay-is-economic-cost`
- `Layer_0/CORPUS-0012-every-venture-risks-loss`
- `Layer_0/CORPUS-0013-non-coin-settlement-exists`
- `Layer_0/CORPUS-0016-opportunistic-bargains-come-from-pressure`
- `Layer_0/CORPUS-0018-rivalry-changes-conditions`
- `Layer_1/CORPUS-0003-arithmetic-resolves-the-venture`
- `Layer_1/CORPUS-0007-rival-buys-the-cart-space`
---
## 10. Success Condition
If the model sees a festival or public gathering and asks how demand, transport, storage, leftovers, and next-location resale change before, during, and after the event, this file is functioning correctly.
<!-- /chunk -->
---