ProjectKILN
Sheet1 OF 6
Rev78e0a2a

A request goes in.A hardened resource comes out.

A developer's request is policy-checked, provisioned, canary-delivered and chaos-tested without a ticket, and every step lands on a hash-chained audit log.

Provisioning a standard Postgres: 11s p50, 16s p95, n=10. The status quo, a Terraform pull request with human review, waits hours to a day.

Subsystems

Pick a block. Each sheet shows the stack it runs on, the problem it had to solve, the custom resource or contract it owns, the decision record that settles it, and the number it produced in the validation week.

GitOps and policy

Turns a claim into real resources, after the org's rules have said yes.

  • Crossplane v2
  • ArgoCD
  • Kyverno
  • CEL
  • Terraform
  • A developer asks for a standard Postgres and never names an instance class, backup retention or network placement. Those are platform defaults, with a custom tier as the escape hatch.
  • Rules are fail-closed validating policies at admission. A denied claim leaves nothing on the cluster and a POLICY_DENY row in the audit log.
  • ArgoCD heals drift on anything stateless and only flags it on anything stateful, so a live database is never reverted without a human.

In the validation week

32 ms

to deny a claim over the storage ceiling. Nothing reached the cluster.

DatabaseClaim and the rule that denied one

apiVersion: platform.internal/v1alpha1kind: DatabaseClaimmetadata:  name: checkout-db  namespace: team-checkoutspec:  parameters:    tier: standard          # standard | custom    storageGB: 500          # the validation week's injected violation    tags:      team: checkout      costCenter: eng-platform# gitops/policies/databaseclaim-org-rules.yaml- expression: object.spec.parameters.storageGB <= 100  message: "POLICY_DENIED rule=storage-ceiling: spec.parameters.storageGB must be at most 100"
ProjectKILN
TitleSubsystems
Sheet2 OF 6
Drawn byGo, Java, Crossplane

Mechanisms

Not animations of the idea. The hash rule, the scoring rule and the blast-radius rule below are the platform's own, running in this page.

Test sheet: break the audit chain

Every row's hash covers its content and the previous row's hash. Change a field and the row fails verification. Rewrite its stored hash too, the way a careful intruder would, and the next row fails instead.

Edit any actor or outcome. Every hash is recomputed here, with the service's rule.

  1. seq 1PROVISION_REQUESTDatabaseClaim/dev03/dev03-db
    prevstoredrecomputed
  2. seq 2PROVISIONTenantDatabase/dev03/dev03-db
    prevstoredrecomputed
  3. seq 3SCHEDULEPod/dev03/dev03-db-0
    prevstoredrecomputed
  4. seq 4DEPLOYCanaryRollout/dev03/dev03-svc
    prevstoredrecomputed
  5. seq 5ROLLBACKCanaryRollout/dev03/dev03-svc
    prevstoredrecomputed

GET /v1/audit/verify

computing…

Calc sheet: score a placement

50 × cost + 30 × fragmentation + 20 × preemption, on four nodes carrying the placement contract. A latency-sensitive pod never sees the spot nodes: they are filtered before scoring runs.

kiln.platform.internal/workload-class

cpu request 1.0

  1. worker-aon-demand, $0.096/h, 1.2/4 cpu
    50 × cost1.00
    30 × fragmentation0.55
    20 × preemption1.00

    86.5

  2. worker-bspot, $0.037/h, 0.4/4 cpu, risk 0.05

    filtered before scoring: workload-class filter

  3. worker-con-demand, $0.170/h, 5.6/8 cpu
    50 × cost0.00
    30 × fragmentation0.82
    20 × preemption1.00

    44.8

  4. worker-dspot, $0.065/h, 4.4/8 cpu, risk 0.12

    filtered before scoring: workload-class filter

the SCHEDULE event this placement publishes

{"action":"SCHEDULE","details":{"outcome":"Bound","node":"worker-a","workloadClass":"latency-sensitive"}}

Plan: cap the blast radius

The agent floors the percentage to whole pods from its own read of the cluster, and rejects a cap that floors to zero rather than rounding up. Faulted pods are hatched, as a section cut would be.

pods matching app=checkout-service: 7

maxReplicaPercentage: 30

floor(7 × 30%) = 2 pods faulted, deterministically, from the agent's own read of the cluster. The other 5 keep serving.

ProjectKILN
TitleMechanisms
Sheet3 OF 6
Drawn byThe platform's rules

Injected failures

During the validation week one identity claimed too much storage, one shipped a bad version, and one ran a full network partition. Each guardrail fired, and each timing was read from audit rows and cross-checked on the cluster in run 34085396203.
  1. Oversized claim

    500 GB against a 100 GB ceiling. Denied at admission; the claim never reached the cluster.

    0 ms25 ms50 ms75 ms100 msdenied at 32 ms
  2. Bad deploy

    A version answering 30% of requests with 500. Rolled back on the mesh, measured from the first traffic split.

    0 s15 s30 s45 s60 srolled back at 50 s
  3. SLO breach under chaos

    A full network partition against a 20% error bound. Aborted, and the iptables rule was gone from the node one second later.

    0 s10 s20 s30 saborted at 25 sfault gone at 26 s
ProjectKILN
TitleInjected failures
Sheet4 OF 6
Drawn byTestPhase7Validation

Invariants

Guarantees that hold structurally, not by convention. Each one is settled by an accepted decision record; records are immutable, and a change means a new record that supersedes it.
  • Org rules are fail-closed Kyverno policies evaluated at admission, before anything is provisioned.

    Decision record 0006
  • Every resource the operator creates carries an owner reference to its custom resource, so nothing outlives it.

    Decision record 0004
  • The chaos agent re-derives the blast radius from its own cluster read, and a fault reverts on a lease dead-man switch if the controller disappears.

    Decision record 0015
  • A resilience score is SLO headroom plus recovery, reported only for a fault confirmed to have landed. A run that tested nothing never reads as a pass.

    Decision record 0016
  • Audit publishing never blocks a reconcile. A Kafka outage stalls no provisioning, rollout or revert, and a dropped publish is counted, not lost.

    Decision record 0017
  • The audit service alone computes the hash chain, under a single write credential no other subsystem holds.

    Decision record 0018
  • The operator holds create-only access to secrets.

    Decision record 0019

The platform does not know, and does not need to know, whether a person or an AI agent submitted the request. An agent gets the same JSON contract, the same bearer token, the same policy gate before anything is provisioned and the same hash-chained audit row as a developer at a keyboard. That is what makes agent-submitted infrastructure safe to allow: the guardrails are in the structure of the platform, not in the judgement of the requester.

ProjectKILN
TitleInvariants
Sheet5 OF 6
Drawn bydocs/decisions

Validation

Ten developer identities, one simulated week compressed into twenty minutes, three injected failures. The table is the run's own artifact, verbatim; this page fails its build if the two ever differ.
Request typeBaseline (status quo)p50p95nError rateGuardrail
Provisioning (standard Postgres)Manual Terraform PR with human review: hours to a day before merge and apply.11s16s100.0% (0/10)
Scaling (storage growth)Manual Terraform PR with human review: hours to a day before merge and apply.49 ms140 ms200.0% (0/20)
Healthy deploy (canary promoted)Manual on-call detection of a bad deploy (minutes to tens of minutes), manual rollback.2m14s2m30s290.0% (0/29)
Bad deploy (injected regression)Manual on-call detection of a bad deploy (minutes to tens of minutes), manual rollback.50s50s10.0% (0/1)auto-rollback fired 1/1
Chaos test (pod-kill, completed)Zero pre-production resilience coverage; failure modes discovered during real incidents.46s52s190.0% (0/19)
Chaos test (injected SLO breach)Zero pre-production resilience coverage; failure modes discovered during real incidents.25s25s10.0% (0/1)auto-abort, fault removed on the node fired 1/1
Policy violation (storage over the ceiling)Manual Terraform PR with human review: hours to a day before merge and apply.32 ms32 ms10.0% (0/1)policy denial fired 1/1
Audit query (actor, time range)Manual compliance log reconstruction across disparate systems, commonly a multi-day effort at audit time.10 ms108 ms100.0% (0/10)

201 audit rows in 23m13s of wall clock, 176 events acknowledged by Kafka, 0 publish failures, chain intact. Run 34085396203 on commit 78e0a2a.

ProjectKILN
TitleValidation
Sheet6 OF 6
Drawn bydocs/METRICS.md