Loomworks — The Engine and Its API Surface, in Plain English

Version. 0.1 Date. 2026-07-05 Provenance. Claude.ai. Written for a reader who is not technical and does not know Loomworks vocabulary yet, but wants a genuinely detailed understanding of what the Engine is and how other things connect to it — not a one-paragraph summary. Sources drawn on. The Operator Layer Discovery v0.4 (the architecture document that named the three-tier structure), the Phase 40 change request (which built the Orchestration API), and the Companion Expertise Note v0.3 (which named the two-API split from the Companion's side). Where this document states something as fact, it is drawing on one of those three. It has not been checked against a freshly-pulled seed or current-status manifest in this session — if anything here has since changed, the seed and manifest govern. Companion document. A more technical version of some of this material lives in loomworks-companion-expertise-note-v0_3, Section 9. This document stands on its own and assumes no prior reading.

In one paragraph

Loomworks has an engine at its center — a piece of software that stores knowledge permanently, with a full record of who said what and when, and turns that knowledge into finished specifications that can become real things: documents, applications, whatever the person needs. Nobody talks to the engine directly. Everyone — a person using the friendly chat interface, a technical person using the advanced view, or a piece of software producing a finished artifact — reaches the engine through one of a small number of well-defined "doors." This document explains what the engine actually does, what those doors are, and why there's more than one of them.

1. What the Engine actually is

Think of the Engine as a very disciplined filing and drafting system. Its job has four stages, which Loomworks calls the four rooms:

• Memory — everything anyone has ever told it, kept permanently, with a note of who said it and when. Nothing gets erased. If something is corrected later, both the original and the correction are kept, so the history is never lost.
• Manifestation — a snapshot of what all that knowledge adds up to at a given moment. Not a raw pile of facts — an organized picture.
• Shaping — that organized picture, arranged for a specific purpose. If someone needs a business plan, Shaping arranges the knowledge the way a business plan needs it. If someone needs a set of software requirements, Shaping arranges it that way instead.
• Rendering — the final step, where the shaped material becomes an actual thing — a document, an application, whatever the destination is.

The Engine's job stops at "producing a complete, well-organized specification." It is not, itself, in the business of holding domain expertise (that comes from the AI, separately) and it is not, itself, in the business of designing a chat experience (that's a layer on top). Its one job is to be excellent at turning intent and accumulated knowledge into something complete and trustworthy enough to build from.

2. Why nobody talks to the Engine directly

If every different kind of user — an ordinary person chatting casually, a technical power-user, a piece of software trying to produce a finished document — all spoke to the Engine's raw internals directly, two bad things would happen. First, the Engine's internal language (its own technical vocabulary) would leak out to people who shouldn't have to learn it. Second, any change to how the Engine works internally would risk breaking everyone who depends on it.

So instead, the Engine sits in the middle, and everything reaches it through a small number of fixed doorways. Loomworks calls this a three-layer picture:

• Above the Engine — the different ways a person's intent gets in. A friendly conversational assistant (the Companion). A more advanced, technical view for power users (the Workshop). And a direct route for sending the Engine raw instructions without a conversational layer at all.
• The Engine itself — the four-room system described above.
• Below the Engine — the different ways a finished specification becomes an actual artifact. This is where the production tools plug in: things that turn a specification into a document, into working software, into whatever the destination requires.

The key idea: the Engine doesn't change no matter which doorway is used to reach it, and doesn't change no matter which production tool turns its output into a final artifact. New doorways and new production tools can be added over time without the Engine itself needing to be rebuilt.

3. The two front doors, explained plainly

There are, in practice, two different "doors" into the Engine today, and it matters which one a given surface uses.

Door one — the direct, technical door. This door speaks the Engine's own internal language — its own words for things like "a piece of recorded knowledge" or "a produced artifact." It's the door the advanced technical view (the Workshop) uses, and it's also available for anyone who wants to send the Engine instructions directly without going through a conversation at all. Nothing is hidden or simplified here; this door shows the Engine as it actually is.

Door two — the translated, everyday-language door. This door was built specifically so that ordinary, non-technical people never have to see the Engine's internal words. Everything that comes through this door has already been translated into plain, everyday language before it reaches the person. This is the door the Companion uses, and it's the door the main Loomworks experience is built on. There is a hard rule enforced by the software itself — not just good intentions — that guarantees the Engine's internal vocabulary can never leak out through this door. If the Engine calls something one thing internally, this door will always describe it to the person in plain terms instead.

Why two doors instead of one simplified door? Because the two audiences genuinely need different things. A technical power-user wants to see exactly what the Engine is doing, in its own terms, with nothing smoothed over. An ordinary person wants a natural conversation and has no reason to ever learn the Engine's internal vocabulary. Building one door that tried to serve both would have made compromises that shortchanged both audiences. Building two doors, each true to its own audience, serves both properly — and it means the everyday-language door can be handed to a completely different piece of software (a different assistant, a different interface) in the future, without anything about the Engine having to change.

What this everyday-language door currently offers. As of now, a person using it can: see a summary of everything going on across all their projects at once; see a list of things waiting for a decision, and act on them; see and download finished work; and have an open-ended conversation that can create and progress a piece of work from scratch. A couple of pieces — getting a narrative summary of a project's story, and being told what follow-up work a finished piece of work is likely to need — are planned but not live yet; asking for them today returns a clear "not available yet" rather than a wrong answer or a silent failure. Consistent with the seed's "only show what is available" rule, nothing pretends to be ready before it is.

4. Below the Engine — how a specification becomes a real thing

The Engine produces a finished, organized specification — but it doesn't build the final artifact itself. That's a separate job, handled by production tools that plug into the Engine through their own dedicated connection point.

The important design idea here: the Engine doesn't care what kind of thing is eventually produced. A specification for a business plan and a specification for a piece of software both go through the same four rooms, in the same disciplined way. What differs is which production tool picks up the finished specification and turns it into the final thing — a document-writing tool, an application-building tool, or something not yet imagined. This is why Loomworks describes the Engine as indifferent to the destination: it does one job supremely well (producing trustworthy, complete specifications) and hands off the very different job of "making the actual thing" to whichever tool is built for that purpose.

5. One more layer underneath — knowing who's who

Separate from all of the above, there's a foundational layer that handles a narrower question: proving who someone is and what they're allowed to do. This doesn't touch the knowledge or the specifications at all — it's strictly about identity and permission, sitting underneath everything else described in this document. Consistent with the seed's authentication rules, a person's identity is never their email address; it's an internally assigned identifier, and sign-in happens through something the person directly controls (a passkey, an authenticator code, or their organization's own sign-in system). This layer is invisible in ordinary use — a person only ever notices it at the moment of signing in.

6. What's actually built today, and what's still ahead

Built and working today: the four-room Engine; the technical direct door (used by the advanced view and available for direct use); the everyday-language door (used by the main conversational experience), including the summary view, the pending-decisions list, the finished-work list, and open-ended conversation for creating and progressing work.

Named and planned, not yet built: a narrative "how is this project going" summary; automatic surfacing of likely follow-up work; support for languages other than English through the everyday-language door; letting a person customize the everyday vocabulary itself (for instance, calling something a "task" instead of a "project," if they prefer); and live, instant updates to the summary view rather than the current refresh-based approach.

7. Why this design matters, in plain terms

If Loomworks only ever had one conversational assistant talking to the Engine, this two-door, layered structure would look like unnecessary complexity. It matters because of what it protects against:

• It protects the Engine from ever leaking its internal jargon to an ordinary person, because that protection is built into the everyday-language door itself, not left to good habits.
• It means a different conversational assistant, or a different interface entirely, could be built on the exact same Engine tomorrow, without touching the Engine at all — because the everyday-language door is a complete, independent surface, not something bolted onto one particular assistant.
• It means the Engine can serve completely different kinds of finished output — a document today, a working application tomorrow, something not yet imagined after that — without changing how the Engine itself works, because the "final artifact" step is handled by a separate, pluggable layer underneath.

The short version: the Engine is the durable, trustworthy core. Everything else — the friendly conversation, the technical view, the finished-artifact production — is a replaceable layer built to reach it, not the thing itself.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — The Engine and Its API Surface, in Plain English — v0.1 — 2026-07-05