TrueClara is designed to make documentation visuals trustworthy without turning the visual layer into a mystery system. This page explains the operating boundaries teams usually ask about during evaluation: where capture runs, what gets stored, how published assets work, and which enterprise controls are available as rollout requirements become stricter.

1. System boundaries

TrueClara is built around a declared capture workflow. Teams define the scenario, keep that definition in version control, and run reshot run --headless locally against their app.

The important security boundary is that the capture process runs entirely on the developer's machine. The product is designed around local CLI execution so teams can reason clearly about where the work runs and how it fits into existing delivery controls.

2. Capture and runtime model

The capture workflow runs locally as part of the same engineering process that already changes the product. Teams build the app, serve it on localhost, run capture there, and inspect the resulting visual change before it is published.

This matters because the visual layer should not require production access, login flows, or a separate manual operator path. The safer model is the one engineering teams already understand: declared configuration, reviewable change, localhost execution, and repeatable runs.

3. Storage and delivery

TrueClara publishes visuals through stable URLs so documentation systems can embed the asset once and keep the reference unchanged as the approved image changes behind it.

For teams starting with the managed delivery path, TrueClara handles the publish layer so the docs team does not have to replace files manually. Today that path is backed by the vendors listed publicly on the Subprocessors page, including the default hosting, storage, CDN, billing, and email providers used to deliver the service.

For organizations with stricter rollout requirements, Enterprise plans can support storage-boundary discussions such as bring-your-own-storage paths. That matters because the question is usually not whether visuals can be delivered, but whether the delivery boundary is acceptable for the buyer's rollout model.

4. Access control and collaboration

TrueClara pricing distinguishes between people who actively manage the workflow and the broader set of teammates who simply need trustworthy visuals. Creator seats are for the people defining scenarios, managing approvals, and controlling delivery. Reviewers should be able to review or benefit from the workflow without creating a per-viewer tax.

Access to workspaces, capture configuration, and delivery settings should stay explicit and reviewable. Where enterprise identity controls are required, TrueClara can support discussions around SSO and SAML-enabled rollout paths.

5. Operational safeguards

Security is not only about storage. It is also about making the workflow inspectable:

• scenario definitions are reviewable
• visual changes can be inspected before publish
• published assets resolve through standard image delivery rather than hidden proprietary embeds
• vendor usage is documented publicly through the subprocessor list

This keeps the operational model legible for engineering leaders, security reviewers, and procurement stakeholders.

6. Enterprise readiness

Mid-market and enterprise buyers often need more than a product explanation. They need a clear rollout story. Enterprise evaluation for TrueClara should center on:

• where capture executes
• where assets are stored and served in the default managed path
• whether BYOS is required for the rollout
• how approvals fit into the engineering workflow
• what identity, support, and SLA controls are available

Those questions are normal. TrueClara should answer them directly rather than hiding them behind generic sales language.

7. Related documents

For adjacent trust and compliance details, review:

• Privacy Policy
• Data Processing Agreement
• Subprocessors
• Terms of Service

Questions about security or rollout requirements can be sent to support@trueclara.com.