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](#14-default-parameters) are expected to move first; principles in
[§ 5](#5-how-resource-control-operates) 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.

`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](#8-delivered-cost). | Reconstructed here from fin-hub booked facts plus allocation and labor evidence. |
| **Transfer price** | Delivered cost × (1 + markup), except Railiance self-consumption. See [§ 9](#9-transfer-price). | 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:

```text
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](#9-transfer-price).
- **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:

```text
transfer_price = delivered_cost × (1 + markup_rate)
```

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

For `entity:railiance` as consumer:

```text
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](#11-credit-interest-and-restricted-consumption).

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.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** | Applied to overdue outstanding. See open question OQ-1. |
| 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. |

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:

```text
new_transfer_charges_allowed =
    max(0, restricted_monthly_consumption − interest_this_month)
```

Worked default at a €1 000.00 overdue balance:

```text
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.

```text
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:

```text
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:

```text
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.

```text
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:

```text
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 (not completed by publishing this file):

1. Add `financial_entity_id` and `procuring_entity_id` to inventory,
   planning-evidence, and control-cycle schemas.
2. Publish a versioned entity register (the table in [§ 3](#3-financial-entities))
   as data, not only as prose.
3. Backfill current `data/resources/` records with procuring and consuming
   entities; leave unknown where evidence is missing.
4. Extend monthly cadence to emit per-entity settlement statements and
   credit-state evaluations.
5. Extend the fin-hub exchange so proposed transfer charges and recognized
   internal payments can be reconciled without becoming a second ledger.
6. Give Railiance operations a consumption-mode signal they can enforce.

Those steps should become a workplan rather than remaining only in this
list.

---

## 17. Open questions for later versions

| ID | Question | V0.1 stance |
| --- | --- | --- |
| OQ-1 | Is 5 % interest annual or monthly? Annual is the V0.1 reading (commercial convention). Monthly 5 % would zero the €50 allowance at the default €1 000 limit (`1000 × 0.05 = 50`). Confirm. | 5 % per annum |
| 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 |
| `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. |