The private workspace

The clear version of the work has one home. Client names, exact figures, document previews, recipients, source links and the restored result appear in a first-party Proxara workspace inside the firm's environment, under the firm's own single sign-on. It is where the preparer reads the work, changes it, and decides what happens next.

Who the workspace opens for

A workspace session is bound to the exact employee and the exact artifact revision, and both are revalidated on every read and every change: current employment, current entitlement, current authority for that piece of work, the recipient projection, and the source and purpose constraints behind it.

A link on its own authorizes nothing. A short-lived capability may start a session, but the workspace exchanges it for an authenticated, recipient-bound session before any clear value renders, so possession of a URL is never the standing authorization.

Where clear values never travel

Clear values do not enter:

• tool output the host can read;
• host-visible structured content or widgets;
• host-controlled messaging;
• the URL or the referrer;
• client telemetry;
• support logs.

An assistant may open or deep-link to the workspace. What it receives is an opaque reference and a model-safe status, and nothing else.

Why the workspace is first party rather than embedded

Sandboxing in an assistant's app surface protects the host from the app's code. It is not a proof that the host provider cannot read what that surface renders, and no vendor documentation makes it one. That is the reason clear rendering happens in an origin the firm controls rather than inside the assistant, and it is the honest version of the claim.

What the preparer does there

• inspects grounding: every conclusion traced to the record and page it came from;
• sees what was found, what is missing, what is ambiguous, and what was deliberately omitted;
• revises the drafted text and the structured fields;
• compares revisions and undoes an edit;
• answers one clarification when scope is genuinely unclear;
• chooses among the next steps the definition permits;
• reviews a consequential effect with the real target and the real payload before confirming it;
• watches execution and its confirmation;
• resumes the job later without rebuilding it from chat history.

The Work Runtime holds the state, not the conversation. A preparer who closes the assistant and comes back later opens the same piece of work at the same revision.

A worked example

A preparer asks what is still outstanding for an 1120-S engagement. The workspace shows the requirement list with each item's status, the client email that carried a statement which was never filed to the engagement, the one requirement genuinely absent, the ambiguous attachment that needs a human decision, the drafted follow-up with the real client and the real recipient, and the two effects proposed: the Outlook draft and the Karbon requirement update.

The preparer edits two sentences, resolves the ambiguous item, and confirms the send. Everything in that paragraph happened in the firm's own workspace. The external model saw the requirement states and drafted the wording.

Where to go next