How It Works | Wrengler Documentation

Wrengler connects places that keep their own data: your machine, your organization's private storage, the project on the platform. It doesn't copy them into one place, and it doesn't act without a direction. This page shows what stays where, what travels between the places, and how the four parts of the workspace hand work to one another.

Federated: what stays where

Each place keeps what it holds. Only typed requests and their results pass between them: a measurement goes to the desk, a number comes back, and a rule reaches the files it governs.

What	Where it stays	What travels, and when
Your model	your machine, in Rhino	a short factual summary when you point a question at the scene (file name, units, site, selection counts and areas, group and layer names), and the numbers a step measured. Never the geometry
Studies	computed on your machine; a saved study is kept in the project as rows	its settings and summary results per group
Files	your organization's private storage, under its roles	passages, when the assistant or a goal reads them for you
Agreed knowledge	the workspace, approved by its lead	facts, quoted as agreed
Conversations	the project	what people asked and what the assistant answered
Rules	the organization	findings and proposed fixes, to the people who can act on them

Who can open what is decided in the database itself, by row-level security, not by the application in front of it. The rules travel with the data. See who can see a project.

Directed: from a direction to a cited answer

A person's direction starts the work, and every line of the answer points back to the study, file or conversation it came from.

Work starts from a person. A question in the chat, a goal, a button in the panel, a rule an owner turned on. Nothing destructive runs without someone approving it: a delete in Rhino waits for Approve, and housekeeping never applies a fix on its own.
Numbers come from recorded facts. A study's result, a tag or an agreed workspace fact, quoted as stored. A number that only a document or a person gives is attributed to them.
Every source is one step away. Answers show what they were built from, and a goal's answer cites every study, file and conversation it read by its reference (S1, F2, C3).

1. Compute: core and context

Compute comes in two kinds.

Core compute is agnostic: the same tools, with the same results, on every surface. The ray engine answers four queries (occlusion, visibility, hemisphere gather and irradiance) and knows nothing about Rhino. The platform's tools read the project's studies, files and tags, and propose changes you confirm.

Context compute is what the place you work in adds: the hardware beside your model, and the functions of the software you have open. When the panel connects, the Rhino plug-in sends a manifest of the operations it can run (read the selection, list groups, select, measure area, filter by facing, colour, hide and show, delete), each with its inputs, outputs and effect. The assistant plans only with what the manifest lists, and the plug-in runs the whole plan in one round trip.

The host sends its manifest. A plan mixes core tools with the host's own operations, and each step runs on the side that can run it.

Studies run in context too, on your own CPU or GPU. The engine picks the fastest backend your machine has; if one fails, the next takes over. Every backend is checked against the same reference, so the answer doesn't change with the hardware.

The engine starts on the fastest backend it has and falls back on its own. Same study, same answer.

2. Goals: long-running work

Some questions take more than one reply. A goal is something you want found out about a project, in your own words, set in the project chat. A planner splits it into up to four parts; workers read the project's studies, files, conversations and notes with the tools each part needs, two at a time; a writer posts the answer, with its sources, into the same conversation. The goal runs on the platform, so you can close the chat while it works.

Time runs left to right. Two parts start together; one is interrupted and starts again on resume, while finished parts are kept; a writer turns the findings into a cited answer. Every step lands in the goal's log.

Every limit is held by the harness, not the model: parts, reads, time and spend. A goal only reads, as you, under the same access rules as the project page. After the answer is written, every number in it is checked against the facts the goal read.

3. Output: images, reports and answers

The same work can end in different forms, and each says how it was made:

Output	Made from	How it shows where it came from
Answers and tables	the project's rows, read by the assistant or a goal	the sources it used, listed under it
Result documents	a saved study's stored results (Save as document on the project page)	the study and result it was written from; marked outdated when the study has a newer result
Images	a genre, its style, and the subject you type	labelled as imagined; the exact prompt shows under the image

A report is written from a study's rows. When the study runs again the report is marked outdated and regenerated from the new rows, while an answer quotes the row itself all along.

An image prompt never carries study results, scene data or document text: only the genre's wording and your subject.

4. Always on: housekeeping and notifications

Your organization's rules run on a schedule, from once a day to every hour: naming, stale files, duplicates, unsupported files, outdated result documents, and classification. Plain checks run first, and a small evaluation model answers only where judgment is needed, once per file. Each finding comes with a proposed fix and goes to the owners, the admins and the lead of the file's workspace. Nothing changes until one of them applies it. Every applied fix is recorded, and renames, moves and archives can be undone.

The organization's schedule turns through the day. Each run checks the files against the rules and sends the findings to the people who can act; a person applies the fix.

What needs you arrives where you are:

The project conversation is the same in Rhino and in the browser, and a goal's answer is posted in it.
The notification center in the dashboard lights for findings to review, invites not yet accepted, knowledge proposals, limits close to full and billing problems.
The audit log records membership, roles, workspaces, projects, knowledge and applied fixes. Admins can read it; nobody can edit it.

One conversation, in Rhino's panel and in the browser: a question asked in one is answered in both, and a goal's answer lands in the same thread.

Not yet

One host. Rhino is the only host today. Another would send its own manifest, and nothing else would change.
Studies from the chat. The assistant can select, measure, colour, hide and show, and delete with your approval. Running a study from the chat is proposed, not built.
Goals across projects. A goal reads the project it was set in.
Notifications outside Wrengler. Findings and answers arrive in the product. There is no e-mail or chat-app delivery yet.
Studies off your machine. Studies run on your own hardware. There is no cloud study service.

Overview: the four parts, and where each stands.
Harness Overview: one typed contract for the panel, Rhino commands and the assistant.
Projects: what a project holds and who can see it.