Core Concepts
Everything ProxyCore runs reduces to a few primitives. Understand these and the rest of the system — the runtime, the language, the audit trail — follows from how they compose.
The primitives
Data objectA typed record with its own history — the unit of state the system reasons about.EventSomething that happened, carrying a payload. Workflows and machines react to events.PermissionA default-deny grant: an actor may take an action on a resource. No grant, no action.StateA checked transition machine — moves are only legal between declared states.WorkflowA named, governed sequence of steps triggered by an event, owning its permissions.AgentA governed actor: a model proposes actions; the runtime allows or denies each one.Audit logA tamper-evident, hash-chained record of what happened, entry by entry.Default-deny permissions
Permissions are evaluated default-deny: an action is refused unless an explicit grant allows it. Grants are declared up front — per workflow, least-privilege — so the access a system has is visible in review rather than discovered in production. This is the single most load-bearing design choice: it means a definition you can read is also the definition of what the system is able to do.
Checked state machines
A state machine declares its states; a transition to a target is only valid if that target is a declared state. Illegal moves and typos are caught when the definition is loaded, not at 2 a.m. in production. Firing an event runs the matching handler, performs the checked transition, and appends an audit entry per action. The runtime can persist a machine's position so it resumes where it left off after a restart.
Workflows & agents
A ProxyLang workflow names a trigger, the permissions it needs, and the steps it runs. An agent is the same governance applied to a model: the model decides which declared action advances a goal, but the runtime decides whether that action is allowed and executes it as a pre-declared write — never free-form. The planner proposes; the runtime disposes.
Across machines, workflows, and agents the shape is the same: capability is declared at definition time, enforced at run time, and recorded in the audit log. Reviewing the definition tells you the blast radius.
The audit log
Actions append entries to a hash-chained audit log: each entry commits to the previous one, so a later edit or deletion breaks the chain and is detectable (tamper-evident). In preview, the runtime can additionally sign periodic checkpoints with an Ed25519 key, so a holder of the public key can verify a log was not regenerated wholesale (tamper-resistant). Coverage is expanding through preview — see the status note.
How proxyweb composes them
The proxyweb runtime wires these primitives behind a single .pxy file: page blocks become pre-rendered surfaces, queries and mutations become the only read/write paths to data, machine blocks become live state machines at /machine/…, commerce drives an audited order lifecycle, and agent blocks run the governed action loop. One readable file, the primitives underneath.
Adapters: from definition to real effects
A definition describes governed behavior; an adapter is what carries an action across the boundary into the real world. Adapters implement the runtime's Adapter trait (in Rust) — a payment provider, an API tool, device I/O — and every call runs under default-deny permissions with an audit entry. In preview the default adapter records actions without executing them, so a machine's action phrases are logged, not run, until a real adapter is bound. You describe in ProxyLang; you connect with an adapter.
Status & limitations
ProxyCore is in active preview. It is not yet offered as a multi-tenant SaaS, and we do not describe it as "governed" or "tamper-proof" as finished claims — audit coverage, isolation, and tenancy are still maturing. The primitives above are real; the production hardening around them is ongoing. Tell us your constraint and we will be straight about fit.