Trust & security
Sensitive operating work needs visible boundaries.
SOVHELM is designed for founder-led groups where work can belong to different ventures, legal entities, roles, stakeholders, and private records. The trust model is practical: publish the company posture, prove who can see what, show how records persist, explain how access changes are reflected, and recover the audit trail later.
Company operator
SOVHELM LLC operates the product.
Run through a company-led public identity and a monitored support route.
Access boundary
Scoped to role and venture.
Workspace, venture, function, role, investor, supplier, assistant and private-record scopes.
Demo separation
Demo never exposes live records.
Public demos and live customer workspaces are kept separate.
AI boundary
Customer data is customer data.
Customer workspace data is not used to train AI models.
Data posture
Company facts and infrastructure facts are separated from personal identity.
SOVHELM publishes company, product, support, data-handling and deployment facts so buyers can review the service at company level. Product controls, support responsiveness, data handling and rollout commitments are documented before sensitive records move in.
Company
SOVHELM LLC
SOVHELM is operated by SOVHELM LLC, a Wyoming limited liability company. Company contact is sales@sovhelm.com.
Current hosted model
Vercel delivery, Supabase persistence.
Live workspace records are designed around Supabase Auth, Postgres, Row Level Security and private storage. The website and app shell are hosted through Vercel.
Access enforcement
UI checks are not the boundary.
Hosted workspaces rely on database-side access rules and server-side privileged actions. Frontend hiding is treated as usability, not security.
Derived data
Derived surfaces follow permissions.
Search, notifications, attachment metadata and AI-assisted signals stop showing restricted content to users who no longer have permission.
01
Tenant and venture separation
Each organization is the tenant boundary. Inside it, ventures, functions, legal entities and private records restrict what each user sees.
02
Role-scoped access
Founder, partner, manager, team, investor, supplier and delegated assistant views expose only the records needed for that role and scope.
03
Persistent operating record
Tasks, comments, attachments, notifications, generated work, access changes and audit events remain traceable over time.
04
Sync and recovery visibility
Live workspaces surface save state, failed-save recovery, account setup and sync diagnostics so records are not silently lost.
Operating chain
Control is checked record by record, not by slogan.
SOVHELM is strongest when the customer can trace the chain from organization to venture, legal entity, function, OKR, project, task, comment, attachment, notification, audit log and search result. Each layer keeps the same visibility boundary.
TENANT
Organization & workspace boundary
SCOPE
Ventures, functions, legal entities & private records
WORK
OKRs, projects, tasks, decisions, risks, obligations & scheduled work
EVIDENCE
Comments, mentions, attachments, notes, audit logs, search & notifications
RECOVERY
Reference IDs, sync status, exports, deletion, support access, AI use & deployment
Assurance matrix
What is controlled in product, reviewed in rollout, and plan-dependent.
Controlled in product
Workspace, venture & role boundaries
Organization scoping, venture separation, function access, private records, delegated assistant scope, permission-aware search and visibility checks.
Controlled in product
Evidence & sync state
Comments, mentions, attachments, notifications, status changes, generated tasks, failed-save recovery, sync visibility and audit logs stay traceable.
Reviewed before rollout
Live and demo separation
Which demo data, live records, user roles, attachments and public guided-demo routes are available to each audience.
Reviewed before rollout
Support & administration
Admin responsibilities, support access expectations, user onboarding, suspended users and reset workflows.
Plan-dependent
Hosting & deployment model
Standard hosted workspaces are the starting point. Regional hosting, private deployment or customer-controlled models can be discussed where required.
Plan-dependent
Advanced assurance requests
Private infrastructure, subprocessor review, custom contractual terms or deeper security review.
Assurance review
Claims stay evidence-based.
Public trust statements are limited to implemented product controls, infrastructure posture and agreed contractual commitments. Customer-specific assurance requests are handled during rollout review.
Founder walkthrough package
Test the operating boundary before sensitive records move in.
A serious rollout starts with representative ventures, legal entities, users, workflow records, private notes, files and access rehearsals. The walkthrough proves the right people see the right work and the wrong people do not.
Request private fit reviewPolicy notes
Detailed control posture
These notes describe the public trust posture. Customer-specific commitments, regions, support access, subprocessors and private deployment terms are confirmed in the relevant order form, customer agreement or data processing agreement.
Access control
SOVHELM is designed to support role-based permissions for founders, partners, managers, team members, investors, suppliers and delegated assistants. Venture-level separation is a core principle so users only see the businesses, entities, projects, obligations, files and records they are allowed to see.
Demo and live workspace separation
Public demo workspaces are separated from live customer workspaces. Demo accounts are intended for product exploration and guided review. Live customer workspaces use the customer’s organization boundary, membership, role assignments, venture scopes and data-store persistence rules.
Persistence and sync recovery
Live operating records are designed to persist through the Supabase-backed data store. The application surfaces sync state, retry behaviour, failed-save recovery and workspace refresh controls so important work is not treated as disposable browser state.
Auditability
Audit logs are intended to help teams understand important changes across ventures, compliance obligations, risks, decisions, comments, mentions, notifications, attachments, generated work and access-sensitive actions.
Customer data and AI
Customer workspace data belongs to the customer. SOVHELM does not use customer workspace data to train AI models. Assisted capabilities are designed to process workspace records for the customer’s own operating signals, subject to the agreed controls and deployment model.
Data protection
SOVHELM production infrastructure uses HTTPS, hardened deployment headers, controlled access to operational systems, service-side privileged actions where required, monitored operational logs, and appropriate backup and recovery practices. Customer data processing is documented as part of workspace onboarding and contractual setup.
Infrastructure providers
The current hosted model uses Vercel for application delivery and Supabase for Auth, Postgres, Row Level Security and private storage. Additional services such as email delivery or analytics may be introduced only for the purpose needed and should be reviewed where a customer has stricter requirements.
Encryption and transport
Public and hosted application traffic is served over HTTPS. Hosted workspace storage uses provider-managed database and storage protections. Customer-specific encryption, key management or private infrastructure requirements should be reviewed before sensitive import.
Hosting and data residency
Incorporation jurisdiction, hosting region, support access, subprocessors and data transfer terms are separate concerns. Customers with stricter sovereignty, client, investor or regulatory requirements can discuss regional hosting, private deployment or customer-controlled operating models before sensitive data is imported.
Support access
SOVHELM support access to customer workspaces is limited to operational support needs. Higher-control plans may include owner-approved support access, access logging and reduced vendor access modes where appropriate for the deployment.
Deletion, backup, and recovery
Workspace retention, backup, export, deletion and recovery expectations should be agreed during onboarding. The product is designed to preserve audit history and reference recovery where appropriate, while sensitive erasure requests need controlled handling so related records do not become misleading.
Assurance status
SOVHELM publishes implemented controls and support commitments rather than unsupported badges. Formal assurance packages, uptime commitments, audit materials or customer-specific security reviews are provided only when they are agreed, documented and available for the relevant customer plan.
Lawful requests
SOVHELM only discloses customer data where legally required. Where legally permitted, we aim to notify the customer before disclosure and challenge requests that are improper, excessive or not valid for the relevant jurisdiction.
Responsible disclosure
If you believe you have found a security issue, contact security@sovhelm.com with enough detail for review. Please do not access, modify, delete or disclose data that does not belong to you.