resource-control/INTENT.md

INTENT — resource-control

Why this repository exists

Railiance consumes compute, storage, network, and managed services from external providers. Those resources create recurring cost, operational dependencies, capacity limits, and switching decisions that cannot be managed reliably from invoices, provider consoles, or deployment repositories alone.

resource-control is the control plane for that portfolio. It records what we consume, why we consume it, who owns it, what it costs, how fully it is used, and which procurement alternatives could provide a better combination of cost, resilience, sovereignty, and operational fit.

The initial provider set is:

• A — Host Europe
• B — Scaleway
• C — Hetzner

The set is a comparison baseline, not a permanent allow-list. Adding a provider requires evidence; retaining one requires continuing value.

What it owns

• A provider-neutral inventory of purchased and proposed resources.
• Resource identity, provider, region, service class, capacity, lifecycle, contract term, renewal/cancellation window, owner, workload, environment, and cost-attribution key.
• Normalized recurring and usage-based cost, including storage, ingress, egress, requests, support, taxes, minimum commitments, and switching cost.
• Demand forecasts and procurement research for new compute and storage.
• Utilization and saturation evidence linked to each resource.
• Budget-versus-actual reporting inputs for fin-hub.
• Periodic rightsizing, consolidation, commitment, migration, and provider switching recommendations.
• Decision records and exit plans for material provider commitments.

Relationship with fin-hub

resource-control answers what concrete resources are bought, used, and replaceable. fin-hub answers what the federation can afford, what its burn rate and runway are, and when resource pressure must change priorities.

This repo publishes normalized inventory, allocation, forecast, and realized cost evidence to fin-hub. It does not create a competing budget ledger or financial allocator.

Operating principles

1. Provider-neutral requirements first. Define durability, recovery, residency, performance, capacity, and exit requirements before comparing product names.
2. Total cost, not headline price. Include traffic, requests, minimum charges, tax, support, labor, migration, and recovery-test cost.
3. No unowned spend. Every resource has an accountable owner, workload, environment, purpose, and cost-attribution key.
4. No untested resilience claims. Backup resources are accepted only after a restore; compute failover is accepted only after a failover exercise.
5. Exit is part of procurement. Record data export, migration path, cancellation window, and credential revocation before commitment.
6. Avoid correlated failure silently. Same-provider placement may be intentional, but the shared failure domain and compensating control must be explicit.
7. Measure before optimizing. Recommendations distinguish observed utilization from estimates and assumptions.
8. Credentials stay elsewhere. Provider keys and billing credentials live in the approved OpenBao/credential-broker lanes, never in this repository.

What it does not own

• Budget authority, runway policy, or financial transactions (fin-hub and human financial authority).
• Workload manifests and service-specific backup procedures (owning rapp-* or workload repositories).
• Provider credentials or payment instruments.
• Cluster-wide deployment governance (railiance-platform).
• Application data retention policy, except to verify that procured resources can satisfy it.

Initial outcome

Procure and operationalize off-host object storage for rapp-postgres continuous WAL archiving and physical base backups, while retaining a separate logical-backup copy. The chosen resource must support a verified full restore and point-in-time recovery, expose its real monthly cost and utilization to fin-hub, and retain a tested provider-exit path.