Wrengler: a federated workspace for directed knowledge

Wrengler keeps your model on your machine and keeps the rest of a project (files, saved results, agreed facts and conversations) in your organization's private area of the platform, where only the people you add can open it. It doesn't act without a direction. This page shows what stays where, what travels between them, and how the four parts of the workspace hand work to one another.

What stays where#

Your model stays on your machine. Only requests and their results pass between the places: 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 area on the Wrengler platform, 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 checked on every request, so a project opens only for the people its workspace admits, whichever app or plug-in asks. See who can see a project.

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).

Compute: core and context#

Compute comes in two kinds.

Core compute is the same everywhere: the same tools, with the same results, wherever you work. At its heart is the compute engine, made of solvers: modern methods, each for one kind of question about a building or a site, written for the GPU first. Ray tracing is the first solver and answers four queries (occlusion, visibility, hemisphere gather and irradiance); more will join it. The engine 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 tells the assistant which actions it offers: read the selection, list groups, select, measure area, filter by facing, color, hide and show, delete. The assistant plans only with those actions, and Rhino carries out the plan.

Rhino says what it can do. A plan mixes the platform's tools with Rhino's own actions, and each step runs on the side that can run it.

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

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

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 parts; workers read the project's studies, files, conversations and notes for each part; 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. Parts run side by side; 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.

A goal works within limits that Wrengler sets and enforces, not the model. 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.

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	labeled 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.

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#

Other design software. Rhino is the only one today. Another would tell the assistant which actions it offers, and nothing else would change.
Editing geometry from the chat. The assistant can add simple geometry, run studies and delete with your approval. It can't move or reshape what's there.
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.
More solvers. Ray tracing is the engine's only solver so far.
Cloud GPUs. Planned. Studies run on your own hardware today. The engine carries no CAD code, so it can be served later.

Overview: the four parts, and where each stands.
Assistant and goals overview: the same checks for the panel, Rhino commands and the assistant.
Projects: what a project holds and who can see it.