Synopsis
The model is the replaceable part
An AWS cost explanation may need billing records, resource configuration, ownership data, deployment history, tickets, and accounting context. The durable system is the controlled evidence and the method used to investigate it. A language model may assist with interpretation, but it should sit inside those boundaries.
Observation
Billing data rarely contains the whole explanation
A CUR line item can establish that spend moved. It usually cannot establish why a team deployed something, whether the increase was expected, or how finance wants the cost allocated. Those answers live in other systems, with different owners and access rules.
Sending all of that context to an external model by default is an architectural decision, not a harmless convenience. The organization should decide which evidence is available, where processing occurs, what leaves the boundary, and what remains reviewable.
Architecture
Four components around an approved model
- Tools collect and normalize evidence through bounded permissions.
- Investigation skills encode repeatable questions, checks, and stopping conditions.
- Business retrieval supplies approved ownership, decision, and operational context.
- FinOps retrieval supplies versioned practices, policies, and investigation knowledge.
Each material conclusion should retain its source, time window, coverage, assumptions, contradicting evidence, and known gaps. ?No evidence of a change? must remain distinguishable from ?the system could not access the evidence.?
Limits
Local-first still needs controls
Running a model inside an enterprise boundary does not settle privacy or security. A real implementation still needs identity controls, network and egress restrictions, retention rules, audit logs, model and tool permissions, and explicit human approval for financial or infrastructure actions.
This is a concept architecture. Model orchestration, retrieval layers, deployment packaging, and confidence calculation remain areas to test. There is no release date implied here.
Kulshan
One existing evidence component
Kulshan demonstrates the local, read-only part of the pattern. It uses customer-controlled AWS credentials, produces inspectable evidence, and does not send telemetry or provide an AWS write path. It is not the entire architecture and does not turn a model into an autonomous FinOps operator.
The open design question is how to connect deterministic evidence to useful interpretation without losing provenance or enterprise control. The architecture repository is the place to challenge those assumptions.
References