The Verb System ​
Traditional programming languages give functions unlimited power by default. If a developer writes a function, that function can usually read any database table, mutate any state, or make a network request to any external server unless explicitly stopped by middleware.
Carotene flips this model. Functions and Loops operate on a Zero-Trust Permission Matrix. By default, they have zero access to your database, zero access to your memory, and zero access to the internet.
To grant the AI execution sandbox permission to do something, you must explicitly declare it using a Verb.
1. Storage Verbs (Disk Access) ​
Storage verbs control access to your store (databases like Postgres or SQLite).
To prevent AI coding agents from hallucinating a for loop and accidentally writing 10,000 duplicate rows to your database, Carotene strictly enforces Cardinality at the architectural level. You must explicitly declare if an operation acts on a single record or multiple records.
creates: Permission to insert exactly one row into a table.createsMany: Permission to perform a bulk insert on a table.reads: Permission to select and fetch data from a table into memory.updates: Permission to modify exactly one row.updatesMany: Permission to perform a bulk update without N+1 queries.deletes: Permission to destroy exactly one row.deletesMany: Permission to destroy multiple rows.
Sandbox Guardrail: If a function is granted creates store.User, the injected database client will physically trap and abort the transaction if the AI attempts to call the create method more than once during execution.
2. Memory Verbs (RAM Access) ​
Memory verbs control access to your volatile state (like Redis on the backend, or Zustand/Redux on the frontend). Because state is not durable, it uses completely different verbs than persistent storage to prevent developers from confusing RAM with Disk.
mutates: Permission to alter a reactive state slice.observes: Permission to listen to a state slice (used primarily byloopto trigger event-driven background workers).
frontend {
function ToggleDarkMode() {
// Explicit permission to change the UI RAM.
// The AI cannot accidentally write this to a database.
mutates state.ThemeContext
implements {
@("Toggle the theme context")
}
}
}3. Lifecycle Verbs (State Machines) ​
Lifecycle verbs are exclusively used to interact with a flow block. They bridge the gap between static data and execution.
triggers: Invokes a named Event within a strict state machine.
When you use triggers, the Carotene compiler automatically enforces Precondition Inference, generating UI guardrails (canExecute) and backend ingress middleware to ensure the transition is mathematically valid before the AI's code ever runs.
backend {
function DispatchOrder(order: store.Order) {
reads store.Order
triggers order.status.Dispatch // Evaluates the state machine preconditions
updates store.Order
implements {
@("Process the dispatch logic")
}
}
}4. Action Verbs (Side-Effects) ​
Action verbs allow your functions to cross boundaries. They are the only way to trigger logic outside of the function's immediate scope. Raw HTTP requests (fetch, axios) are completely banned inside the AI execution sandbox.
calls: Permission to execute anotherfunctionor trigger an externalintegration(like Stripe or SendGrid).
backend {
function ProcessRefund(orderId: store.Order.id) {
reads store.Order
// The only way the AI is allowed to talk to the outside world
calls integration.Stripe.IssueRefund
implements {
@("Execute the refund")
}
}
}5. Security Verbs (Authorization) ​
The final category of verbs dictates who is allowed to execute a workflow.
requires: Enforces an identity check before the function or loop is allowed to run.
This verb is the foundation of Carotene's authentication model. If a function requires an identity, the Carotene compiler automatically generates the JWT verification middleware, the session checks, and the frontend redirect logic (e.g., kicking an unauthenticated user back to the login screen).
backend {
function DeleteAccount(user: store.User) {
// Generates the auth middleware to ensure the user is logged in
requires AuthenticatedUser
deletes store.User
implements {
@("Delete the user data")
}
}
}