Radiant

Git-backed, YAML-defined configuration assets. Radiant is where every other primitive looks up the rules, schemas, templates, and policies it operates against.

What it owns

Radiant centralises four jobs: registering Git repositories the tenant trusts as a source of configuration, registering individual YAML assets out of those repositories, validating those assets against schemas, and resolving stable references to a specific effective version at runtime. It is the only primitive that talks to Git.

Everything declarative on the platform — pricing rules, cancellation policies, stage flow definitions, message templates, vendor configs, frontend view definitions — lives in Radiant. Other primitives carry an opaque radiantAssetId and call resolve when they need the parsed payload.

Concepts

Repository: A registered Git remote the tenant can read assets from. Tracks credentials, default branch, and sync state. Soft-deletable; soft-delete leaves dependent assets unresolvable rather than cascading.
Asset: A logical YAML document inside a repository — identified by path plus schema kind. The asset is the stable identity; its content changes through versions.
Version: An immutable snapshot of an asset's parsed payload at a particular Git commit. Versions are append-only. Each version carries its source ref, the schema it was validated against, and the parsed payload.
Alias: A stable, human-readable name that resolves to either a pinned version (tag behaviour) or the latest version on a channel (branch behaviour). Aliases are how runtime code refers to "the production pricing rules" without baking in a version id.
Channel: A named track of an asset (main, staging, preview). Aliases follow a channel; resolve returns the head of the channel at request time.
Resolution: The single runtime entry point. Given an assetId + channel or an aliasName, return the effective version's id and parsed payload. Cached, validated, and tenant-scoped.

API surface

All endpoints are versioned under /radiant/v1/, return RFC 7807 problem details on error, and read tenantId from the bearer token. Single-item by default; explicit /batch variants exist where genuine bulk demand exists.

Method	Path	Purpose
POST / GET	`/radiant/v1/repositories`	Register or list Git repositories for the tenant.
GET / PUT / DELETE	`/radiant/v1/repositories/{id}`	Fetch, replace, or soft-delete a repository.
POST / GET	`/radiant/v1/assets`	Register a YAML asset out of a repository, or list assets.
POST	`/radiant/v1/assets/{id}/versions`	Publish a new immutable version of an asset.
POST / GET / PUT	`/radiant/v1/aliases`	Manage stable names that resolve to a version or channel head.
POST	`/radiant/v1/resolve`	Resolve an `assetId + channel` or `aliasName` to an effective version.
POST	`/radiant/v1/validate`	Validate a payload against a registered schema before publication. Planned.

Example

Resolve the production pricing rules for tee-time bookings:

POST /radiant/v1/resolve
Content-Type: application/json
Authorization: Bearer <token>

{
  "aliasName": "pricing.tee-time.production"
}

Response (abbreviated):

{
  "assetId": "asset_01J8K2…",
  "versionId": "ver_01J9TQ…",
  "schemaKind": "seldon.pricing.v1",
  "sourceRef": "main@7c4a2e3",
  "payload": {
    "currency": "USD",
    "rules": [
      { "dim": "side", "value": "front", "windowAdjPct": 10 },
      { "dim": "side", "value": "back", "windowAdjPct": 0 }
    ]
  }
}

How it fits with the rest

flowchart LR
  Git[Git / YAML] --> R(Radiant)
  R --> S[Seldon]
  R --> D[Daneel]
  R --> Sp[Speaker]
  R --> Other[other primitives]

Radiant is referenced, not depended on, by every other primitive. Seldon offers carry a radiantAssetId pointing at their pricing and cancellation YAML. Speaker templates resolve through Radiant. Daneel workflow definitions live in Radiant. Frontend ui_view assets that the rendering runtime consumes are Radiant assets too.

The cross-primitive contract is intentionally minimal: opaque id in, parsed payload out. No primitive needs to know how Radiant stores or syncs anything.