luma

catwalk

Runway for intelligence.

01 — premise

Every feature, eventually, wants intelligence.

A Resource wants describing — for search, for tagging, for accessibility. A Review's feedback wants summarising before sign-off. A Brief wants turning into a draft Plan. A derivative wants checking against its source. A vendor's PDF wants its line items pulled into an Order.

Without a shared abstraction, each one arrives in its own shape — its own provider config, its own auth handling, its own way of giving the Model access to data, its own audit trail. Each new feature, another patch of glue.

Catwalk is somewhere for that to live once instead of many times: Models, prompts, Runs, and a controlled view of the data.

02 — the shape of it

Three primitives.

The rest of Catwalk is built from them. They are Domain entities — tagged, ACL'd, portable.

i.

Model

a handle on an LLM
Internally, a Cortex.

A connection to a specific Model — Claude, OpenAI, or one of the Vertex variants — behind a uniform call. The rest of Luma doesn't hold a vendor SDK; switching provider is configuration.

ii.

Skill

a piece of intelligence
(Skill, of a Guild)

A named, versioned procedure. A custom prompt, a chosen Guild, and a list of which Models it can run on. Authoring a Skill is configuration; the Guild underneath determines what the Model is given to do.

iii.

Run

one trip down the runway
Internally, a Sashay.

One execution of a Skill against one Model. A persistent record — durable, observable, restartable. The thing that gets queued, scheduled, and reaped if it stalls.

03 — Skills, and the Guilds beneath them

Every Skill belongs to a Guild.

The Guild is the type. It decides what kind of work the Skill performs: what slice of Luma the Model sees, what inputs the Skill takes at start time, and the controller code that drives the LLM loop. A Guild is a small Java class — on the order of a hundred lines — declaring its slots, its inputs, and the body of its loop. Adding a new Guild is engineering work; configuring a Skill on top of an existing Guild is not.

A Skill is the configured part authored on top of a Guild: a name, a prompt, the Models it can run on, the tags and tunings that distinguish it. One Guild can host many Skills — each a different prompt, a different scope, a different audience.

Versioned, with a memory of its own past. Every meaningful edit becomes a new snapshot, with the predecessor preserved. Quick edits in a sitting collapse together; once a Run begins, the version it started with is locked, so no edit can rewrite the prompt mid-flight or after the fact.
Bound to Models loosely. A Skill says either any Model in the Domain, this specific list, or any Model with these tags. The actual Model is chosen when the Run starts. Re-pointing a Skill from Anthropic to OpenAI to Gemini doesn't touch its prompt.
Layered prompts. The system prompt the Model sees is assembled from the Guild's class hierarchy — shared guidance at the base, specifics at the leaf, terminated by the version's own prompt. Common guidance lives once, where it can be edited once.
Public and private inputs. Some inputs are decided per-Skill and frozen with the version (the persona, the scope); others are per-call (the specific brief, the specific Asset list). The Guild decides which is which.

04 — a Run

A Run is a record.

Every invocation lives as a row from the moment it's queued. It carries state, a short status, progress from zero to one, an iteration index when applicable, an append-only log, and links to the entities it consumed or produced. A week later, the row still tells you what it touched and what it said.

Pinned at the start. The prompt and the Model it began with are pinned into the row. Edits to either after the fact don't perturb the historical view of what ran.
Heartbeat-gated. Models hang; networks fail. A Run that hasn't reported progress for five minutes is reaped, with the failure recorded against the row rather than left as a dangling worker thread.
Restartable and abortable. Aborts are a first-class state transition; stalls become diagnostic events on the same log; failed Runs can be inspected like succeeded ones.
The Model reports itself. Three protocol entries are reserved for the Model to call back into Luma: log a line, set a status, advance progress. Those land in the same log the worker is writing to.

05 — the bridge

A bounded window
into the data.

The harder part of LLM work isn't the Model. It is giving the Model access to data — scoped to what the task needs, governed by the same access controls the calling user has.

Catwalk does this through MCP, the protocol the current generation of Models speak. The unit of access is a slot.

A slot is a named handle on a slice of Luma — a single record, a set of records, or a parameterised query, over one Domain entity type. Each Guild declares its slots when a Run starts, drawing on the Skill's configuration and the Run's per-call inputs to bind concrete data into each one. Together with a policy (read-only by default; mutation an explicit, audited opt-in), that bag is the Model's view of Luma for the duration of the Run.

06 — inside the bag

The tool surface.

Whatever sits inside a Skill's declared slots is presented to the Model as a small set of tools — listed, described, paginated, projected. The Model talks to a typed surface, projected through the same field rules a Luma client uses.

Reads. Listing slots, reading specific records, walking references between them, paginating long lists — all of it scoped to the bag.
Mutations, by exception. Changing data is an explicit opt-in on the policy, gated to the highest privilege tier in the first cut. Mutations run through the same code paths the API uses — the same validators, the same notifications, the same audit trail.
Domain operations. A method on a Domain entity that has been marked exposable becomes a tool when that entity is reachable through a slot. Adding a new operation to the Model surface is a one-line annotation, not a new pipeline.
Binaries when allowed. Files, images, video: when the Skill opts in, the Model can ask for a short-lived signed URL for any Storable in the bag.

07 — vision

And it sees, too.

A small family of vision tools layers on top — eight Gemini operations, exposed over Luma's storage layer. A Skill that wants to look at an image, a video, or a PDF asks for it by reference; the rest is plumbed.

describe
extractText
ask
classify
detect
compare
analyzeVideo
analyzeDocument

When a stored object lives in GCS, the vision Model pulls it directly using its own credentials — no signing, no egress. When it doesn't, a short-lived signed URL is minted on demand. Skills that don't need vision don't see the tools; installations without Vertex configured don't expose them at all.

08 — built on what is already there

It looks like Luma.

Catwalk leans on Luma DOM — com.intrepia.luma.dom, the package that gives Luma a clean, navigable object graph over its persistent state. Assets, Projects, Folders, Plans, Orders, Accounts, Workflows, Reviews — each is a Luma DOM class wrapping a row, with lazy accessors that hydrate parents, references, and related entities on demand from a shared Context. Server-side scripts and JSP-driven notification templates already use Luma DOM to read Luma data without hand-rolling SQL or chasing IDs.

Building Catwalk's bridge on Luma DOM is the point, not an accident. An LLM working through MCP behaves the way a Luma DOM consumer already does: ask for a record, follow a reference, page through a collection, ask for more. Luma DOM's lazy hydration through a shared Context is exactly that pattern; the bridge exposes it over the wire. A Skill's slots hold Luma DOM objects, and the Model's reads run through the same accessors, the same caching, and the same access-control hooks a workflow script would. New entities reachable through Luma DOM become reachable through the bridge without a separate schema layer.

Domain entities. Models, Skills, and Runs are Domain entities, with the same tags, Actor link tables, UI handlers, and notifications other facets use.
One ingest path, three ownerships. On-disk configuration and HTTP envelope upload/download share one upsert path. Each row carries a management state: File — deployment-owned, read-only via the API. Local — runtime-owned, authored through the UI or API. External — owned by another system, synced from outside.
References that travel. Cross-entity links inside an envelope — a Skill referring to its allowed Models, a Run referring to the Assets it produced — serialise as portable signatures (signature + uuid or uri), never as raw database IDs. The same envelope round-trips between installations.
Async work on the existing machinery. Runs queue onto the same Queue table other long-running work in Luma uses, and a worker drains them with the same agent-loop pattern. No new scheduler, no new pool.

09 — what ships, what doesn't

Groundwork.

Catwalk is the foundation. The shape is fixed; the plumbing is in place. What's reachable today and what would still take work are worth being plain about.

today

Two Guilds in the box.

Two Guilds ship. One operates on a collection of Resource Assets, iterating per item with a bounded context. One operates within the scope of a single Project Asset. New Skills can be authored on either — prompt, Model bindings, tag scopes — without touching code.

tomorrow

More of Luma DOM reached.

Folders, Plans, Orders, reviews, briefs, structured documents — entities not covered by the shipped Guilds. Reaching them means writing a new Guild: a small Java class declaring its slots and its loop. Self-contained engineering work, but engineering work.

today

Vision, where it's wired.

The Vertex vision tool family is in the box. A Guild that opts in gets the eight operations over Storables. The shipped Guilds opt in; new vision-driven Skills on those Guilds are a prompt edit away.