Operating Temper

Rather than a flat "it's all handled," everything below sorts into three tiers kept visibly apart: what the architecture fixes, what it makes extensible (with the edges still being found), and what is genuinely yours. An evaluator is better served by that separation than by a claim that blurs them — and keeping them apart is exactly what makes the rest of this trustworthy. The same separation runs through the four dimension pages this hub leads into.

The vocabulary — telos, cognitive map, an event-sourced substrate — is grounded in cognitive maps (the concrete on-ramp) and the commitments underneath in theory (the why). This page assumes them and points back rather than retelling them.

Invariant across every deployment, proven in the artifact and replay-verified. This is the strongest tier: proven, not promised. Adopt Temper and you adopt all of it.

• The event-primary ledger — every change is an event, and the current state is a projection of them.
• The convention-agnostic kernel — it never branches on a deployment's conventions.
• Teams-RBAC over homed boundaries — access is scoped through team grants over owned regions.
• Actors as entities — every writer, agent or integration, is an entity meeting the same event shape.
• Administration is event-sourced — governance acts are events, so the audit exists by construction.
• The invocation envelope — an accountability-grain run with a telos/scope binding and a terminal outcome.
• The delegation launch-gate — a delegated run is authorized before it can act, never after.
• Authorship invisible to affinity — who wrote a thing never tilts how concepts relate.

The runtime choice is localized to a thin contract the substrate never reads: the temper-agents crate depends on the substrate, never the reverse, and the kernel never branches on which runtime woke an agent. The shape of the delegation problem has held across the platforms modeled so far — Vercel's Eve durable agents and Claude Managed Agents are both first-class runtime bindings, and runtime and residency stay orthogonal axes rather than tangling together.

So the claim is extensible shape with partial neutrality, not a flat "runtime-neutral." The seam, named plainly: those runtimes are enum variants in the contract, so adding one today is a patch to the contract crate, not a line of configuration — a deliberate refusal to abstract too early. What becomes pure configuration versus what the substrate must model is still being settled by running on real runtimes, and that line is expected to move as we learn. A live research front, not a permanent limitation — walked through under deployment, and the same honest seam is the forward-exciting note insights closes on.

The deployment chooses, and this page does not pretend otherwise. None of these has a single right answer the project could publish for you:

• Which runtime your agents run on, and the residency of where their tools execute.
• The token budget a delegated run is paced against.
• The tenancy model — single-tenant, or many internal sub-tenants with per-tenant boundaries.
• Per-tenant integration — which systems write the ledger, for which tenant.
• The trigger cadence that wakes an agent — event volume, a clock, salience past a floor.
• The observability scope — which metrics matter, what you alert on and retain.
• How guarded the administrative surface must be — from a thin operator surface to a separated, audited, SAML-backed plane.

Where this page can only point at a finding and a contract rather than a shipped fact, it says so — tier 2 is named as tier 2, never quietly promoted to tier 1. The unblurred version is the one worth holding to: this is invariant; this is what we happen to run, and you can swap it; this is genuinely yours.

The operating story splits four ways. Each is a dimension a deployment shapes, and each has a part the architecture fixes and a part that's yours:

• Deployment — topology, tenancy, per-tenant integration, and where agents run. The dimension where one organization's Temper diverges most from another's, with the runtime seam stated as a seam.
• Governance & administration — who may author a map versus who may reshape the access graph beneath every map, how guarded that second power must be, and why administration is auditable by construction.
• Observability & audit — is the system healthy, and what did it know and why did it change: two questions, two homes, with the responsibility boundary named.
• Insights — what becomes possible once agents leave correlated, reasoned traces: a queryable provenance of how a shared understanding formed. The forward-looking close.