What is published, and what is not published yet

Whether it is safe to put a client's drawing into a piece of software is a question about published policy, not about how confident a website sounds. So this page is written the way a procurement reviewer would want it written: what is published is stated as fact with the document it comes from, and what is not published is named as a question with no published answer.

Two published documents carry a large part of the answer, both effective 2 July 2026 and both from Agentic Visual Pty Ltd: the Privacy and data handling page, and the Terms of Service, which say they govern this website and the Visual Studio service. Between them they state what is collected, what it is used for, that customer content is hosted on Google Cloud infrastructure, how long several kinds of record are kept, your right to ask for access, correction or deletion, that you keep ownership of everything you upload, and that you may use the visuals you generate for your business purposes provided you review them first. Both are linked at the end of this page, and the sections in between say which parts of them answer which question.

Three things this site states everywhere also hold here. Studio produces communication visuals for your staff to review. It does not send, publish or share anything on your behalf, so a result reaches a client because a person on your side put it there. And your people remain responsible for professional judgment, product suitability, technical specification, customer commitments and final approval.

What is not published is named as such. Neither document states a position on whether customer material is used to train models, a security certification or audit report, an encryption arrangement, who inside Avisual can see a file, any team role or administrative control, a retention rule for uploaded drawings or for generated visuals, a self-service deletion path, or which providers process material during a Studio run. Those are carried below as open questions with a note in place of an answer, and the last section says how to ask about them before you upload anything.

A run has a shape this site already publishes: your staff member chooses a workflow, supplies the inputs that workflow declares, an agent team produces reviewable work, and your staff member decides whether the result is used. The Privacy page covers a good part of what happens to the material in between — what is collected, what it is used for, where it is hosted, how long several kinds of record are kept, and what you can ask for.

It does not cover all of it. Where the facts below run out, the questions that follow them are listed rather than answered, because a plausible-sounding data-handling sentence is believed, quoted into a procurement questionnaire, and repeated by Studio Consultant long after anyone remembers it was a guess.

This is the one place where the published documents come close enough to be misread. The Privacy page says aggregate, de-identified usage data is used to measure and improve service quality, and that personal information is not sold. Neither of those is a statement about whether the content you upload is used to train a model, and this page will not stretch them into one.

This is contractual ground, so the wording below stays close to the Terms' own rather than becoming a friendlier restatement of it. The Terms open by saying they govern this website and the Visual Studio service, and their content and generated-visuals sections are where an ownership question is actually answered.

A security section is where a page most often stops describing a product and starts describing an aspiration, usually in a font surrounded by badges. v0.5 section 21's visual direction says it plainly: no seals, no compliance badges, no certifications not actually held. The written equivalent is below — one published fact about the legal frameworks involved, and then the questions nobody has published an answer to.

Studio assists and automates repeatable visual work. Your people remain responsible for professional judgment, product suitability, technical specification, customer commitments and final approval.

In practice that means Studio does not approve a design, verify a dimension, produce construction documentation, or make a technical judgement about buildability, compliance or fitness for purpose. A visual is a communication artefact: no output on these pages establishes dimensional accuracy, technical approval or a colour-calibrated match against a physical product.

The Terms of Service put the same boundary in contractual terms: outputs are reviewable previews and decision support rather than assured representations of materials, measurements or installation results, they should be reviewed before you rely on them, and a virtually staged or digitally furnished property image must be disclosed as such. That last one is an obligation you take on, not a caveat Avisual takes on.

It also means Studio does not decide that a result is good enough. That judgement belongs to the person who owns the client relationship, which is why the review step is a stage in the operating model rather than a note underneath one.

Two failure modes are worth stating before you rely on this in front of a client. The first is a run that fails outright, which is visible and inconvenient. The second is a run that returns something plausible and wrong — a material reading as the wrong species, an element the source did not contain, a change nobody asked for — which is invisible until somebody who knows the job looks at it.

That second mode is why every workflow ends with a person reviewing the result against the source, and why these pages publish no success rate and present no output as verified. Adjusting the direction and running again is the normal shape of the work rather than a sign that something went wrong — a first run is not the expected number of runs. What a workflow does with an input it was not designed for is not described here, so the safe assumption is the one the review step already requires: check the result against the source before anything reaches a client.

Guest evaluation exists to settle one question: whether a relevant workflow does something useful on the kind of material you have. Business use is your own material, your own staff, and the same workflow run repeatedly until it is part of how the work gets done. They are different arrangements and the trust questions attached to them are different too.

A team or process pilot starts as a conversation about your process rather than as a button on this page, and a business trust question is the route to that conversation today. What differs between the arrangements beyond the fact below is not published, and the items below say so rather than implying that guest use is the more cautious option or that business use is the safer one.

The sections above are deliberately the answer rather than a signpost to one — v0.5 section 21 asks that trust information not be hidden inside legal documents. The documents are still where the full text lives, and both are linked below, with their contact addresses.

For the questions neither document covers, ask before you upload rather than afterwards. That is a real recommendation rather than a polite one: those questions are genuinely open, and an answer given to you directly is the only one available today.