railiance-platform/INTENT.md
codex 21db3d9b50
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Name S3's Quality-dimension responsibilities in INTENT
S3 has carried Q1 Security and Compliance for months - approval gates,
delegated apply, revocation semantics, front-door readiness - without the
dimension ever being named. Naming it does not change what this layer does; it
makes the responsibility legible to the rest of the fleet.

Also draws the line the other way: observability is Q2 and belongs to
railiance-telemetry, so S3's obligation is to emit through the standard contract
rather than build its own monitoring. The recoverability half is Q3 and remains
unowned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:20:13 +02:00

4.4 KiB

INTENT

This file captures why this repository exists, the direction it is moving toward, and the kind of system it is meant to become. It is intentionally aspirational and stable, not a description of current implementation.


One-liner

The shared platform-services layer — the dependable foundation of stateful services (data, cache, secrets, object storage, messaging) that everything else builds on.


Why This Exists

Applications should not each reinvent, operate, and secure their own databases, caches, secret stores, object storage, and message brokers.

When every application carries its own copy of these services, the result is:

  • duplicated operational burden,
  • inconsistent durability and backup guarantees,
  • and a sprawling, hard-to-secure surface.

This layer exists to provide those stateful services once, operably, and consistently, so that everything built above it can assume a reliable, backed-up, secure substrate instead of building one each time.


The Mission

Where we are going.

To become the canonical home for shared, stateful platform services — where data persistence, caching, secret custody, object storage, messaging, and their backup and recovery are provided as well-operated, independently evolvable services behind stable interfaces.

This means:

  • Stateful services are operated to clear durability, availability, and recovery guarantees
  • Secret material has a dependable custody and delivery mechanism
  • Consumers depend on stable service interfaces, not on internal topology
  • The layer can evolve — operators, engines, versions, topologies — without breaking what is built on it

Core Principles

1. Shared, Not Duplicated

Provide each stateful service once and well, rather than letting every application carry and operate its own.

2. Stable Interfaces over Internal Detail

Consumers bind to service contracts. The operators, engines, and topologies behind those contracts can change underneath without forcing changes above.

3. Durable by Default

Persistence, backup, and tested recovery are part of providing a service — not an afterthought added later.

4. Secure Custody

Secret material is held and delivered through a dependable authority, never scattered across the consumers that need it.

In OAS terms this layer carries Q1 Security and Compliance on the Quality dimension — approval gates, delegated apply, revocation semantics, and front-door readiness. That practice was built before the dimension was named; naming it does not change what S3 does, it makes the responsibility legible to the rest of the fleet.

5. Operable and Observable

Every service is monitored, recoverable, and diagnosable as a first-class property.

Observability itself is not this layer's to own. It is Q2 and belongs to railiance-telemetry; S3's obligation is to emit through the standard contract rather than to build its own monitoring. The recoverability half is Q3, currently unowned across the fleet.

6. Independently Evolvable

The layer can adopt new operators or engines, and migrate between them, without forcing rewrites in the things that depend on it.


What This Is (Conceptually)

This layer is:

  • a shared platform-services layer
  • a dependable substrate of stateful infrastructure
  • a custody and delivery point for secret material
  • a backup and recovery home for platform data
  • a stable interface surface for the services consumers depend on

What This Is Not

This layer is not:

  • an application or business-capability provider
  • the infrastructure or cluster runtime beneath it
  • an identity or authorization authority
  • a place for application-specific logic

It is the stateful foundation that other systems rely on.


Direction of Evolution

This layer is expected to evolve toward:

  • Consolidation of stateful services behind well-operated operators
  • Stronger durability, backup, and disaster-recovery guarantees
  • Dependable runtime secret custody and delivery
  • Clear, versioned service interfaces for consumers
  • Self-healing and observable platform services

Guiding Question

How can the stateful foundation an entire landscape relies on be made dependable, secure, and recoverable — while remaining free to evolve underneath everything built on it?