The model
Temperic is being built around a simple idea:
A capability should be understandable in terms of what it promises, what supports those claims, and what is happening around it when it operates.
Today, those answers are often scattered across prompts, code, workflow definitions, tests, documentation, logs, permissions, monitoring systems and the knowledge of the people who built them.
That becomes increasingly difficult as software is assembled from automations, AI agents, tools and reusable components that can act with less direct human involvement.
Temperic is an attempt to make more of that meaning explicit.
Its current model is organised around three things: Clarity, Confidence and Visibility.
Clarity
Before we can reason about whether a capability works, we need to know exactly what is being claimed.
What does it commit to?
A promise describes the behaviour or outcome a capability says it will provide.
It should be specific enough that somebody can meaningfully ask whether the promise has been met.
A promise is not the same as an implementation detail. Different implementations may provide the same promise, and the same implementation may change over time.
What exactly is the thing making that promise?
Claims and evidence need an identity to attach to.
That means knowing which capability, implementation and version they describe.
Without identity, evidence can easily become detached from the thing it supposedly supports. A result from an earlier implementation may say very little about the version running today.
Where does the promise stop?
Every useful promise has boundaries.
Scope makes explicit the situations, inputs, environments and behaviours a capability does and does not claim to cover.
Saying what a capability does not promise is often as important as saying what it does.
A narrow claim that is well understood is more useful than a broad claim whose limits are hidden.
Confidence
Once we know what is being claimed, we need to understand what supports it.
Temperic does not assume that every claim has the same kind of certainty.
Some things may be structurally guaranteed. Some may have survived testing. Some may be based on observations. Others may currently be assumptions.
Those distinctions should remain visible.
What supports the claim, and to what standard?
A basis is the evidence or reasoning that supports a claim.
That support may take different forms.
A property might be proven by construction.
A behaviour might have been tested repeatedly without being refuted.
A claim might be supported by observed executions.
Or it may simply be an assumption that has not yet been adequately tested.
Temperic aims to preserve those differences instead of compressing them into a single undifferentiated statement of confidence.
What remains unknown?
Not knowing something is itself useful information.
A gap represents something that cannot currently be established, something for which evidence is missing, or something whose status remains unresolved.
Temperic treats unknowns as things to preserve and inspect rather than automatically filling them with an inference.
Knowing where the evidence stops is part of knowing what can safely be concluded from it.
What actually happened when it ran?
A capability's definition tells us what should happen.
Its record tells us what did happen.
Execution records provide evidence about real behaviour: which path was taken, what information was used, what actions occurred, where failures appeared and what the resulting state was.
Over time, those records can provide new evidence about the capability itself.
Visibility
Capabilities rarely exist alone.
They call other capabilities, depend on shared systems, affect downstream processes and change over time.
Understanding an individual capability therefore requires some understanding of the wider system around it.
What capabilities exist?
An inventory makes the capabilities present across an organisation or system visible.
Without one, reusable behaviour tends to disappear into workflows, repositories, prompts, integrations and individual teams.
Knowing what exists is the first step towards understanding duplication, ownership, reuse and change.
What depends on this, and what happens if it changes?
A capability may be relied upon by other capabilities, systems, people or business processes.
Changing it can therefore have consequences beyond the place where the change was made.
Impact makes those relationships visible so that a capability can be considered in the context of what depends on it and what it depends on.
What is it doing operationally?
A system can be correctly specified and still behave unexpectedly in operation.
Observability provides information about what capabilities are actually doing: executions, failures, latency, volume, state and other operational behaviour.
This complements the capability's promises and evidence rather than replacing them.
A log can tell us what happened.
It does not, by itself, tell us whether what happened was what should have happened.
As software becomes more capable, the distance between what a system can do and what people can confidently understand about it can grow.
That problem is particularly visible in automation and AI-agent systems.
A workflow may run successfully without making its assumptions clear.
An agent may reach a plausible conclusion without showing what actually supports it.
A reusable component may be changed without knowing which systems rely on its previous behaviour.
A system may be observable without being understandable.
Temperic is being built to bring those questions closer together.
The aim is not to make every system certain.
It is to make clearer:
what is promised, what is supported, what remains unknown, and what is actually happening.
Temperic is in alpha.
The model described here represents the direction in which the product is being developed. It should not be read as a claim that every part of that model is already implemented.
As development progresses, we intend to publish working examples, technical decisions, limitations, experiments and evidence from applying the model to real capabilities.
Temperic is developed by StableOps, a software company working on automation, integrations, AI-agent systems and the infrastructure needed to make them more understandable and dependable.
StableOps also undertakes selected implementation work for businesses and delivery partners.