Omnilogic Labs
// PRODUCT // TRELLIS

A rigid structure. Whatever you grow on it.

Prompt-to-app tools give people freedom and take away safety. Traditional frameworks give developers safety and demand expertise. Trellis is the bet that you can have both: a professionally maintained framework underneath, AI-generated code on top, and a validation pipeline standing between the agent and production.

The name is the design. A trellis is a rigid structure a plant grows on. The plant grows in any direction the structure supports, and the structure keeps it from collapsing under its own weight. Users never see the trellis. They see their plant.

SPEC_ID: TRELLIS // STATUS: IN BUILD // CLIENT-FUNDED
FIG. STRUCTURE_AND_GROWTH
REF: TRELLIS-00A lattice structure carrying growth: a fixed frame with generated units attached to it

01 // THE PROBLEM

The people closest to the work can now build software. They cannot operate it.

A subject-matter expert can describe an application and watch it appear. What they cannot do is see the parts that decide whether it survives contact with real users: how sessions are handled, who is allowed to read which row, where the API key ends up, what a schema change does to yesterday's data.

Those parts do not fail loudly during the demo. They fail later, in production, in ways that are expensive and sometimes unrecoverable. The current answer is to ask the agent nicely not to make those mistakes.

REF: TRELLIS-01
// WHERE GENERATED APPS BREAK
  • Secrets pasted into generated code, then into logs and agent context
  • Access rules checked in the browser and nowhere else
  • A destructive migration applied to live data
  • One bad page taking the whole deployment down
  • No way to tell which commit is actually running
REF: TRELLIS-01 // THE FAILURES ARE STRUCTURAL, NOT STYLISTIC

02 // WHAT IT IS

Three layers, and only one of them is generated.

Trellis splits an application into a part professionals maintain forever and a part an agent writes on request. The boundary between them is enforced by the build, not by a prompt.

REF: TRELLIS-L01
foundation

The core

Immutable and versioned. It owns the HTTP server, routing, auth and sessions, user management, the database and its entire physical schema, background jobs, outbound network access, and secrets. Generated code can call it. It cannot change it.

REF: TRELLIS-L02
api

The capability SDK

The only API surface generated code is allowed to touch: typed packages for auth, storage, jobs, outbound HTTP, and the design system. Everything the agent writes composes these and nothing else.

REF: TRELLIS-L03
widgets

The generated layer

Pages, components, and server actions the agent writes at the user's request. No schema, no migrations, no database code of any kind. Every change passes validation before it deploys.

What the person sees is the familiar loop: describe what you want, watch it appear, keep talking. They are never asked about auth strategies, connection pooling, or migrations, because those questions were answered once, by professionals, underneath.

03 // WHO IT IS FOR

Companies whose experts should be shipping, and whose engineers should be setting rails.

The pattern keeps recurring in our client work: a business with deep domain knowledge, a pile of prototype apps built by non-engineers, and no safe way to move any of it into production. The instinct to have the business side build its own front ends is right. What is missing is the structure underneath that makes it survivable.

Trellis is that structure. Editing content, adding pages, reshaping a workflow: cheap and safe. Anything that writes to the backend or introduces a new data shape: a capability the framework grows, deliberately, by people who own it.

// FITS
PROTOTYPE CONSOLIDATIONMULTI-TENANT PLATFORMSNON-ENGINEER AUTHORSGOVERNED DEPLOYMENTHORIZONTAL

04 // HOW IT WORKS

Small units. Typed doors. A gate before production.

REF: TRELLIS-H01
dashboard_customize

The unit

The atom of the generated layer is a directory the agent owns: a page, its server actions, its tests. Each unit is built, validated, versioned, and deployed on its own. A unit that fails validation keeps serving its last good version, so one broken page is one broken page.

REF: TRELLIS-H02
lock

The action

Server logic takes exactly one shape: a registered action with a typed input, a typed output, and a declared auth requirement. There is no way to express an unvalidated endpoint, and an action that declares no auth rule fails the build.

REF: TRELLIS-H03
verified

The gate

Between the agent and production sits a validation pipeline: type checks, the import boundary, generated tests, and the auth contract. Secrets are held in the core vault and injected by reference, so a key never appears in generated code, agent context, or a log line.

REF: TRELLIS-STACK
// STACK

TypeScript end to end, in the framework and in the generated layer. PostgreSQL is the only persistence layer, with the ORM living inside the core as the single data-access implementation. A core-owned shell loads each page unit as its own lazily built bundle, because a single whole-app build would reintroduce exactly the failure the unit model exists to prevent.

STACK: TYPESCRIPT // POSTGRESQL // CORE-OWNED SHELL // PER-UNIT BUNDLES

05 // THE HARD PART

Making the bad outcome impossible instead of discouraged.

Prompting an agent to be careful is a probability, not a guarantee, and the failures it is being asked to avoid are the ones that do not show up until later. So the capability is removed rather than gated.

  • The import resolver refuses everything outside the SDK, so there is no filesystem, no process environment, no arbitrary fetch, no dynamic import
  • The agent never sees a schema and never writes a migration; storage is a managed API over a fixed physical layout the core designed once
  • Outbound calls pass through a core proxy with a per-app domain allowlist the owner approves
  • Isolation is per unit, so a failure has a blast radius of one page
FIG. THE ENFORCED BOUNDARY
REF: TRELLIS-02A hard boundary between a maintained core and a generated layer, with a validation gate between them

06 // STATUS

In build, and funded by the work that produced it.

Trellis is the durable core of a live platform engagement: a client moving roughly two dozen prototype applications and an ERP onto one system they own, with their own people continuing to build on top of it afterwards. The foundation ships inside that engagement first, on real users and real data, before it is offered on its own.

That is the flywheel this lab runs on. A client pays for the specific problem. The part that recurs becomes the product.

REF: TRELLIS-STATUS
STATUS: IN BUILD
PROVING GROUND: A LIVE MULTI-TENANT PLATFORM MIGRATION
MODEL: SUBSTRATE + MIGRATION TEMPLATES
// NEXT

Have a pile of prototypes and no way to put them in production?

That is the problem Trellis was built out of. Tell us what your team has already built, and we will tell you what it would take to make it survivable.

Start a conversationarrow_forwardSee all products