resource-control/docs/TermsOfResourceProcurement.md

Terms of Resource Procurement

Field	Value
Version	V0.1
Status	Baseline operating framework; open for refinement
Effective	2026-08-14
Owner	resource-control (operating policy for the control plane)
Approving authority	Human financial authority of Binky Hedgehog GmbH
Supersedes	none

These terms tell resource-control how to attribute, estimate, evaluate, and internally charge infrastructure resources once the six financial entities operate on separate banking accounts. They are a management-accounting framework, not a commercial contract between legal persons and not a second booked ledger.

V0.1 records the founder's stated baseline. Parameters in § 14 are expected to move first; principles in § 5 should move more slowly.

---

1. Purpose

Binky Hedgehog GmbH is separating Binky, Frontier, Railiance, Netkingdom, Helixforge, and Coulomb onto individual banking accounts so each can develop as a profit center under the umbrella company. Railiance procures and manages IT resources for the group. The other centers consume those resources on published internal terms.

A center that cannot settle is not treated as a permanent draw on the group. The credit facility in § 11 caps further exposure and gradually restricts consumption, so an unprofitable center must improve market access, offerings, and pricing — or fade as its allowance shrinks. It is not killed on the first missed settlement.

resource-control is the control plane that makes that arrangement operable:

• every expense, estimate, usage observation, and expense evaluation belongs to exactly one financial entity;
• Railiance's delivered cost is reconstructed from provider facts, allocation evidence, and attributable labor;
• consuming entities are charged that cost plus the published markup;
• monthly settlement, overdue interest, credit-limit state, and restricted consumption are computed from those records;
• booked money, legal invoices, tax treatment, and payment execution stay with fin-hub and human financial authority.

This document is the baseline rule set for that loop.

---

2. Legal and organizational setting

The legal person today is Binky Hedgehog GmbH. The intended later identity is Operational Knowledge GmbH. The rename is a milestone, not a change of entity identifiers in this control plane.

Until a profit center is incorporated separately, the six names are internal financial entities of one GmbH. They will have dedicated bank accounts (or equivalent account partitions). Internal charges under these terms are transfer prices between profit centers, not customer invoices and not intercompany invoices between distinct legal persons.

Consequences for V0.1:

• resource-control produces settlement statements and credit-state evaluations. It does not emit a legal invoice, book a DATEV posting, or move money.
• fin-hub remains authoritative for booked financial facts, tax and currency treatment, budgets, commitments, burn, and runway, per docs/fin-hub-resource-control-contract-v0.1.md.
• Consolidation and elimination of internal markup at GmbH level is an accounting concern, not a resource-control concern.
• If an entity later becomes a separate legal person, these terms become the draft of a real supply agreement. That step requires human legal and tax review; it is out of scope for V0.1.

---

3. Financial entities

Every cost object in resource-control is associated with one of the following entities. Identifiers are stable. Display names may change. Adding, splitting, or retiring an entity is a versioned change to these terms.

ID	Display name	Role under these terms
entity:binky	Binky	Umbrella / company-operations profit center. Residual corporate identity of Binky Hedgehog GmbH. Consumes IT resources like any other center. Holds non-IT company costs (desk, Steuerberater, banking fees) outside this document.
entity:frontier	Frontier	Recognized profit center. Commercial mandate is defined by its own canon, not by this document. Consumes IT resources on the same terms as the other non-provider centers.
entity:railiance	Railiance	Sole procuring and managing entity for in-scope IT resources. Pays external providers. Delivers usage to the other centers. Consumes resources for its own platform at cost, without markup.
entity:netkingdom	Netkingdom	Profit center for identity, access, security, and operational sovereignty. Consumes IT resources on transfer-price terms.
entity:helixforge	Helixforge	Profit center for the capability-forging product line. Consumes IT resources on transfer-price terms.
entity:coulomb	Coulomb	Profit center for capability discovery, packaging, and related products (including Coulomb Social). Consumes IT resources on transfer-price terms.

Existing portfolio identities continue to work as join keys. They do not replace the financial entity:

Existing key	Financial entity
tenant:coulomb, workload coulomb-social	entity:coulomb
tenant:friendly:binky, workload rapp-qonto	entity:binky
workload helix-forge	entity:helixforge
Railiance platform, cluster, host, forge, and shared services	entity:railiance as procuring entity; consuming entity is whoever uses the allocated share

A workload, tenant, or repository may belong to only one financial entity at a time. Shared infrastructure is procured by Railiance and allocated to consuming entities; it is not owned by several entities at once.

Unknown association is a control defect. It is recorded as financial_entity_id: null with an explicit gap, never as a silent default to Railiance or Binky.

---

4. Roles

4.1 Railiance — provider of IT resources

Railiance procures and manages at least:

• compute
• storage
• network
• domains and DNS
• intelligence (model APIs, reserved weights storage, inference capacity)
• databases and managed services
• shared platform services (cluster, forge, identity runtimes, ingress)
• licenses required to operate the above

Railiance may add resource classes already represented in schemas/resource-inventory.schema.json without a terms revision. A class outside that model needs a schema change and a note in the next terms revision.

Railiance:

1. holds the provider contract and the provider billing relationship;
2. pays the provider from the Railiance bank account;
3. commissions, operates, measures, and retires the resource;
4. exposes usage and allocation evidence into resource-control;
5. invoices the consuming entities internally at cost plus markup;
6. receives settlement into the Railiance bank account.

4.2 Consuming entities

Binky, Frontier, Netkingdom, Helixforge, Coulomb, and Railiance-for-itself are consumers. A consumer:

1. declares demand and service requirements in its owning repositories;
2. accepts the allocated share of shared resources it actually uses;
3. is charged the transfer price for that use;
4. pays Railiance from its own bank account on the settlement calendar;
5. may carry a published overdue balance up to its credit limit.

4.3 Binky Hedgehog GmbH — umbrella

The GmbH is the legal counterparty to external providers and banks until that is deliberately changed. Profit-center accounts are internal partitions of that legal reality. The future Operational Knowledge GmbH name does not, by itself, change procurement authority, entity IDs, or these rates.

4.4 Human financial authority

Only a human may:

• open or close entity bank accounts;
• change markup, interest, credit-limit, or payment-term parameters;
• approve a provider contract or a commitment that binds the GmbH;
• grant an entity a non-default credit limit;
• waive interest or write off an internal balance;
• suspend or restore an entity's consumption.

---

5. How resource-control operates

These rules are the organizational change this version introduces.

5.1 Association is mandatory

Every record that estimates, observes, allocates, or evaluates cost or usage carries:

Field	Meaning
financial_entity_id	The consuming entity that will bear the transfer price. Required on forecasts, usage observations, allocations, expense evaluations, and settlement lines.
procuring_entity_id	The entity that pays the external provider. V0.1 default: entity:railiance.

Inventory records carry both. A dedicated resource used by one center has that center as financial_entity_id. A shared resource has entity:railiance as procuring entity and an allocation method that produces per-consumer shares, each tagged with a consuming financial_entity_id.

No inventory item, forecast, actual, allocation, optimization case, or variance row may be published without a consuming entity or an explicit unattributed gap.

5.2 Two money views, never mixed

For each resource and period, resource-control keeps three figures separate:

Figure	Definition	Authority
Delivered cost	What it cost Railiance to provide the resource in the period. See § 8.	Reconstructed here from fin-hub booked facts plus allocation and labor evidence.
Transfer price	Delivered cost × (1 + markup), except Railiance self-consumption. See § 9.	Computed here; proposed to fin-hub.
Booked fact	What was posted as a provider invoice, credit, tax line, or (later) an internal settlement posting.	fin-hub only.

A forecast is not a transfer price. A transfer price is not a booked payment. Variance is explained against the figure that was actually predicted.

5.3 Control loop with entities

The existing loop is unchanged in stages and now closed per entity:

demand[entity] → estimate[entity] → compare → approve → procure[Railiance]
  → commission → allocate[entity] → monitor[entity]
  → evaluate expense[entity] → settle[entity → Railiance]
  → apply credit state[entity] → optimize → renew / migrate / retire

Monthly cadence already defined in docs/portfolio-operating-cadence.md gains one output: a settlement statement per consuming entity, plus a credit-state evaluation that Railiance operations can enforce.

5.4 What this repository will not do

Unchanged from INTENT.md, restated so these terms cannot be read as a license to exceed it:

• no contract signature, no payment, no DATEV booking;
• no provider or banking credentials in this repository;
• no customer invoicing (external customers remain a fin-hub / commercial concern);
• no silent approval of consumption above a restricted allowance.

---

6. Resource classes in scope

In scope when procured or managed by Railiance for any financial entity:

• compute instances and cluster capacity
• object, block, and backup storage
• network, ingress, egress, and connectivity
• domains, DNS, and certificates
• intelligence: commercial model APIs, reserved weights, inference hosts
• databases and managed data services
• shared platform services and self-managed services on rented capacity
• licenses required to run the above

Out of scope for these terms (tracked elsewhere, typically Binky / fin-hub):

• office rent and non-IT company overhead
• Steuerberater and statutory accounting fees
• banking plan fees, except when a fee is the direct cost of a resource-specific payment instrument
• founder-private cards and uncleared Auslagen, until they are booked to an entity and a resource

A cost that is out of scope must not be laundered into a Railiance transfer price.

---

7. Association, allocation, and identity

7.1 Join keys

The common join already required by INTENT.md is extended, not replaced:

• resource_id
• financial_entity_id (new, required)
• procuring_entity_id (new, default entity:railiance)
• service_id, workload_id, tenant_id, environment
• cost_attribution_key
• provider account, accounting period, source evidence

tenant_id remains a workload/tenancy key. It is not the profit-center key. Mapping from tenant or workload to financial_entity_id is an explicit table, not a string prefix rule.

7.2 Dedicated versus shared

• Dedicated. One consuming entity. Delivered cost of the resource in the period is that entity's cost. Transfer price follows § 9.
• Shared. Railiance procures. An allocation driver (already required by the portfolio model) splits delivered cost across consuming entities before markup. Each share is then marked up independently.
• Unattributed. No transfer price is issued. The cost remains visible as a Railiance residual and as a coverage defect. It is not spread by convenience.

7.3 Railiance self-use

Capacity Railiance uses to deliver the platform (control plane, forge used as a production tool of Railiance, cluster system pods, backup of Railiance's own state) is consumed by entity:railiance at delivered cost. No markup. That cost may later be allocated into a shared driver that other entities pay; it is not marked up twice.

---

8. Delivered cost

Delivered cost is the amount it cost Railiance to provide a resource (or an allocated share) in the accounting period, in EUR.

V0.1 cost base, when known:

Component	Included	Source
Provider infrastructure charges	yes	fin-hub booked facts joined to resource_id
Usage, egress, request, and minimum charges	yes	same
Provider credits and discounts	yes, as reductions	fin-hub corrections
Tax	as treated by fin-hub; never reconstructed here	fin-hub tax_status
External services required to deliver the resource	yes	booked facts or priced evidence
Attributable Railiance operations labor	yes, at the current internal labor rate	resource-control labor evidence
Setup / migration in the period it is recognized	yes	forecast and actual setup evidence
Internal markup	no — applied after cost	this document
Corporate overhead of Binky (desk, StB, …)	no	out of scope
Uncertainty / missing price	recorded as unknown, not as zero	existing portfolio rule

Missing components stay null. A transfer price is issued only for the known portion of delivered cost, and the statement labels the unknown remainder. Inventing a complete price from a partial base is forbidden.

Currency is EUR. Other currencies are converted only by fin-hub; this repository does not imply a rate.

---

9. Transfer price

9.1 Rule

For a consuming entity other than Railiance:

transfer_price = delivered_cost × (1 + markup_rate)

V0.1 markup_rate = 0.20 (cost plus 20 %).

For entity:railiance as consumer:

transfer_price = delivered_cost

Markup is Railiance's internal margin for procurement and management. It is the same rate for every consuming entity and every in-scope resource class unless a later version publishes a class-specific or entity-specific exception.

9.2 What the 20 % covers

The markup is Railiance's compensation for:

• holding the provider relationship and payment timing risk;
• managing the resource;
• providing monthly usage evidence and settlement;
• extending the credit facility in § 11.

It is not a customer margin, not a tax, and not a license to hide unallocated cost. Unallocated cost stays unallocated.

9.3 Estimates

Forecasts and procurement comparisons show, per consuming entity:

• estimated delivered cost (low / base / high as today);
• estimated transfer price (same scenarios, markup applied);
• estimated effect on the entity's credit headroom.

A decision that only quotes provider list price is incomplete under these terms.

---

10. Settlement

10.1 Period and statement

• Accounting period: calendar month M.
• resource-control closes usage, allocations, and delivered-cost reconstruction in the first week of M+1, on the existing monthly observation cadence.
• It then issues one settlement statement per consuming entity that has any charge, credit, interest, or open balance.

Statement contents (minimum):

• financial_entity_id, period, statement date, due date
• line items: resource_id, usage summary, delivered cost by component, markup, transfer price
• known-cost total, unknown-cost remainder
• prior outstanding, payments recognized (as projected from fin-hub), interest for the period, new transfer charges, new outstanding
• credit limit, headroom, consumption mode (open or restricted)
• restricted new-consumption allowance for the coming month, if applicable
• Railiance pay-to account reference (non-secret)
• consuming entity pay-from account reference (non-secret)

10.2 Payment terms

• Settlement is monthly.
• The statement is payable within 10 calendar days of the statement date.
• Payment is from the consuming entity's bank account to the Railiance bank account.
• If the statement is issued late, the due date follows the statement date, not month-end. Consumers are not punished for a late close.

Recognized payment is a fin-hub fact (or a human-confirmed bank evidence projection). resource-control does not declare a payment from a chat message or an unverified screenshot.

10.3 Railiance self-settlement

Railiance's own consumption at cost is recorded for P&L completeness. It does not generate a payment instruction to itself.

---

11. Credit, interest, and restricted consumption

This facility is internal working capital from Railiance to the other centers. It is not a bank loan and not an external credit line.

11.0 Purpose of the restriction

The default limit and the restricted allowance exist to bound group risk when a profit center degenerates into a cost center.

A center that does not earn enough to settle with Railiance is not terminated on the first overdue statement, and it is not allowed to keep drawing resources without limit. Outstanding may remain outstanding for as long as needed. New consumption is strangled: first by the €1 000 trigger, then by the €50 monthly cap, then a little more each month as 5 % annual interest takes a slice of that cap.

That residual room is deliberate. At the default limit the center still has about €45.83 of transfer-price consumption per month — enough to keep a thin operation alive while it improves market access, offerings, and pricing, not enough to grow at the group's expense. A center that does not recover will fade toward irrelevance as interest compounds on the overdue balance and the usable allowance stays small.

Human authority may still kill, recapitalize, or waive. These terms only automate the squeeze, not the sentence.

11.1 Parameters (V0.1 default)

Parameter	Default	Notes
Credit limit	€1 000.00	Per consuming entity. A named entity may be granted a different limit by human financial authority.
Payment term	10 calendar days	After statement date.
Extension	unlimited in time	An overdue balance is not time-barred by these terms.
Interest	5 % per year	Confirmed 2026-08-14 (OQ-1). Applied to overdue outstanding.
Interest convention	simple, monthly	interest = overdue × 0.05 / 12 at each subsequent month-end close, on the overdue principal (and previously capitalized interest if any remains unpaid).
Restricted monthly consumption	€50.00 transfer price	Applies when outstanding ≥ credit limit.
Restricted allowance	max(0, 50.00 − interest_this_month)	New resource consumption, not a waiver of interest. Leaves a thin residual at the default limit so the center is squeezed, not frozen.

Railiance as self-consumer has no credit limit under these terms. External provider credit is a provider-contract concern.

11.2 When a balance is overdue

A statement amount not recognized as paid by the due date becomes overdue outstanding. Interest starts the following calendar day and is quantified at the next monthly close using the monthly convention above. There is no additional late fee in V0.1.

11.3 Credit limit as a consumption trigger

The credit limit is a consumption-control threshold, not a legal debt ceiling.

When outstanding ≥ credit_limit at evaluation time, the entity enters restricted consumption for the next operating month:

new_transfer_charges_allowed =
    max(0, restricted_monthly_consumption − interest_this_month)

Worked default at a €1 000.00 overdue balance:

interest_this_month = 1000.00 × 0.05 / 12 = 4.17
new_transfer_charges_allowed = max(0, 50.00 − 4.17) = 45.83

That €45.83 is transfer price, so delivered cost that may be newly consumed is 45.83 / 1.20 = 38.19 (Railiance self-use is not in this mode).

Interest continues to accrue for as long as any overdue amount remains. These terms do not set a maximum duration.

If the entity pays down below the limit, the next evaluation returns it to open consumption. Partial payment first reduces interest, then overdue principal (V0.1 convention; accountants may supersede).

11.4 Enforcement

resource-control publishes the consumption mode and the remaining allowance. It does not throttle a cluster.

Enforcement is operational:

• Railiance platform / procurement refuses or defers new orders that would exceed the allowance;
• elastic usage that would exceed the allowance is rate-limited or rejected where the platform can do so;
• already-committed provider contracts (annual domains, committed VMs) are not silently cancelled — they are flagged to human financial authority if they would breach the allowance;
• shared-platform system safety (backups, identity, ingress needed to keep an already-running service from data loss) may continue, and the overage is recorded as an exception, not hidden.

A restricted entity that nevertheless accrues more than the allowance creates an exception line on the next statement and stays restricted.

11.5 Waivers and limit changes

Only human financial authority may raise a limit, lower a limit, waive interest, or grant a temporary unrestricted window. The grant is a dated decision record; resource-control stores the resulting limit, not the conversation that produced it.

---

12. Banking

Each financial entity will have its own bank account or a dedicated partition of the GmbH's banking (for example a Qonto account or sub-account). V0.1 requirements:

• resource-control stores only non-secret account references (account_ref), never credentials or payment instruments.
• Provider charges for in-scope resources are paid from the Railiance account.
• Internal settlement is paid from the consuming entity account to the Railiance account.
• Binky may continue to hold the legal banking organization. That does not make Binky the procuring entity for IT resources.
• Until an entity's account exists, charges may be computed and statements issued, but payment recognition stays unknown and the entity's credit state is reported rather than pretended to be settled.

Opening the accounts is human / banking work. It is a dependency of live settlement, not of adopting the association rules.

---

13. Authority boundaries

Concern	Authoritative party
These terms, rates, limits	Human financial authority; this file is the published text
Resource identity, usage, allocation, forecasts, transfer-price calculation, credit-state evaluation	resource-control
Booked provider cost, tax, currency, budgets, runway, recognized payments	fin-hub
Provisioning, telemetry, enforcement of restricted consumption	Railiance platform / cluster / hosts repos
Demand and service requirements	Owning workload repositories
Provider contracts, bank execution, limit waivers	Human financial authority
Credentials	Approved OpenBao / credential-broker lanes

This document does not amend docs/fin-hub-resource-control-contract-v0.1.md. Internal transfer prices are a new planning/settlement artifact that fin-hub may later book. Until that exchange exists, statements here are proposed charges with provenance, not booked spend.

---

14. Default parameters

All amounts EUR. Changing a row without changing a principle is still a terms revision (V0.1.1 or V0.2) so historical statements remain auditable against the version that produced them.

ID	Parameter	V0.1 value
P1	Markup on delivered cost (non-Railiance consumers)	20 %
P2	Markup on Railiance self-consumption	0 %
P3	Settlement period	calendar month
P4	Statement issue	first week of the following month
P5	Payment term	10 calendar days from statement date
P6	Interest rate	5 % per annum
P7	Interest convention	simple monthly, rate / 12 on overdue outstanding
P8	Default credit limit	1 000.00
P9	Restricted monthly consumption cap	50.00 transfer price
P10	Restricted allowance	max(0, P9 − monthly interest)
P11	Credit-limit meaning	consumption trigger, not a legal cap
P12	Overdue duration	unlimited under these terms
P13	Currency	EUR
P14	Procuring entity	entity:railiance
P15	Labor rate used in delivered cost	the rate already used by resource-control cost models; not redefined here

---

15. Worked examples

Figures are illustrative. They use V0.1 parameters and two-decimal money.

15.1 Ordinary month

Coulomb's allocated August delivered cost is €200.00 (known). No prior balance.

transfer_price     = 200.00 × 1.20 = 240.00
statement_date     = 2026-09-01
due_date           = 2026-09-11
outstanding        = 240.00
credit_headroom    = 1000.00 − 240.00 = 760.00
consumption_mode   = open

Coulomb pays €240.00 from its account to Railiance on 2026-09-08. Recognized payment clears the balance. Interest is zero.

15.2 Extended payment

Same statement. No payment arrives by 2026-09-11.

At the September close the €240.00 is overdue. Monthly interest:

interest = 240.00 × 0.05 / 12 = 1.00

If Coulomb also consumed €100.00 delivered cost in September (€120.00 transfer price) and still has not paid:

new_outstanding = 240.00 + 1.00 + 120.00 = 361.00
consumption_mode = open          # still below €1 000

Interest continues each month until the overdue amount is paid. There is no automatic write-off.

15.3 Default limit reached

Helixforge has €1 000.00 overdue outstanding at month-end.

interest_this_month            = 1000.00 × 0.05 / 12 = 4.17
new_transfer_charges_allowed   = max(0, 50.00 − 4.17) = 45.83
max_new_delivered_cost         = 45.83 / 1.20 = 38.19
consumption_mode               = restricted

If Helixforge consumes exactly that allowance and pays nothing:

new_outstanding = 1000.00 + 4.17 + 45.83 = 1050.00

The balance may exceed the limit by restricted-month charges. The entity stays restricted. If instead it pays €200.00, outstanding falls to €850.00 plus any new allowed charges, and the next evaluation can return it to open.

---

16. Adoption in resource-control

V0.1 is in force as operating policy once this file is published. Schema and inventory adoption follows; until then, association is required in new evidence prose and in any new record that can already carry an owner or tenant, and is an explicit gap on historical records that cannot.

Adoption work is the operational facility in workplans/RESOURCE-WP-0005-resource-procurement-facility.md (residual of RESOURCE-WP-0004): entity register and terms parameters as data, schema association, portfolio backfill, transfer-price and credit-state engine, monthly settlement statements, entity views on forecasts and the portfolio report, and the fin-hub / Railiance handoff.

---

17. Open questions for later versions

Resolved

ID	Resolution	Date
OQ-1	5 % per year, not per month. Monthly 5 % would zero the €50 allowance at the default €1 000 limit and freeze the center. The annual rate is part of the squeeze: at the default limit the center keeps a thin residual (~€45.83 transfer price) so it can try to recover rather than being cut off.	2026-08-14

Still open

ID	Question	V0.1 stance
OQ-2	Should committed provider terms (domains, reserved instances) be cancellable automatically in restricted mode?	No; flag for human decision
OQ-3	Should markup apply to labor, or only to provider cash cost?	Labor is in delivered cost, therefore marked up
OQ-4	Should Binky, as umbrella, pay markup to Railiance, or receive platform services at cost?	Binky pays markup; elimination is accounting
OQ-5	What is Frontier's commercial mandate, and does it consume a distinct intelligence class?	Entity exists; mandate is out of scope here
OQ-6	When a center is incorporated separately, do these terms become a written supply agreement with USt?	Requires StB / legal review
OQ-7	Payment waterfall if a payment does not cover interest + principal?	Interest first, then principal
OQ-8	Daily versus monthly interest accrual?	Monthly close is enough for V0.1
OQ-9	Default limit per entity, or a group limit?	Per consuming entity
OQ-10	Does Railiance mark up pass-through domains and LLM APIs at the same 20 %?	Yes, one rate until a class exception is published

---

18. Change control

• A new version is a new heading in this file or a successor file that names the version it replaces.
• Statements and forecasts must record the terms version that produced them. Later versions do not rewrite historical transfer prices.
• Parameter-only changes increment the minor label (V0.1.1). Principle or entity-set changes increment the minor or major label (V0.2 / V1.0).
• Human financial authority approves versions that change P1–P12.
• Editorial clarification without numeric or role change may land as a dated note under the current version.

---

19. Related documents

Document	Relationship
INTENT.md	Control-plane purpose; these terms specialize entity association and internal charging
SCOPE.md	Repository boundary; in-scope work now includes entity-associated settlement evidence
workplans/RESOURCE-WP-0005-resource-procurement-facility.md	Builds this document into the operational facility
docs/fin-hub-resource-control-contract-v0.1.md	Authority split with fin-hub; not amended
docs/portfolio-operating-cadence.md	Monthly observation cadence that will emit settlement statements
docs/forecast-actual-control.md	Forecast immutability and variance; transfer prices follow the same append-only rule
binky-control/INTENT.md	Umbrella company purpose and Operational Knowledge GmbH rename
binky-control/EcosystemMap.md	Pillar descriptions for Coulomb, Net Kingdom, Railiance, Helixforge

---

20. Document history

Version	Date	Change
V0.1	2026-08-14	Initial baseline: six financial entities; Railiance procures and manages; cost plus 20 %; monthly settlement; 10-day payment; 5 % p.a. interest with unlimited extension; €1 000 default credit limit; restricted consumption €50/month minus monthly interest.
V0.1	2026-08-14	OQ-1 confirmed: interest is 5 % per year. Documented the restriction as a risk bound and a gradual squeeze on centers that degenerate into cost centers — not an instant kill.