How Varendo works

Varendo separates what the user wants from how your interface presents it. Each stage narrows behavior and attaches evidence. Read the flow once; every other page refers back to it.

1. 01

   Resource and Catalog

   Describe entities, fields, stable identity, relationships, meanings, and available operations.

2. 02

   Intent

   A bounded request: browse People, inspect one Product, edit a Ticket, or analyze a registered measure.

3. 03

   Task

   The pure compiler turns intent into required outputs, operations, fields, form bindings, and an optional view preference.

4. 04

   Result

   Evaluation returns rows plus identity, scope, grain, precision, completeness, lineage, and revision.

5. 05

   Recipe and Experience

   Registered policy selects a view that satisfies the Task, environment, accessibility, and host constraints.

6. 06

   Region commit

   The runtime rechecks authority and read revisions, transfers valid state, then commits or keeps the previous safe UI.

Follow one request#

Given a registered people resource, this input travels through every stage above and returns a typed receipt:

render call

const receipt = await app.render({
  regionId: 'people-main',
  intent: {
    version: '1',
    id: 'browse-engineering',
    kind: 'browse',
    resource: 'people',
    fields: ['name', 'team'],
    filter: { op: 'compare', field: 'team', comparison: 'eq', value: 'Engineering' },
  },
});
// receipt.status is 'renderer-ready', 'needs-input', 'denied', 'cancelled',
// 'unsupported', or 'failed' — never an unbounded promise of pixels.

A button, route, test, or agent sends the same shape. Each stage can narrow it or stop it; none can widen it into unregistered behavior.