Company access should expand only after evidence and approval.
Vellward's current trust model starts with a narrow supervised pilot. The company defines what the Closer may see, what it may prepare, which routine actions are permitted, and which decisions must stop for founder approval. This page separates controls that exist now from pilot requirements and future work.
Control status
Implemented now, pilot-scoped, or planned.
“Implemented now” describes a current public or billing boundary. “Pilot-scoped” describes a rule that must be configured for each accepted company. “Planned” means Vellward is not claiming general availability today.
| Control | State | Current public position |
|---|---|---|
| Public product and authority boundary | Implemented now | The current offer identifies one supervised Closer and keeps consequential decisions with the founder. |
| Pilot-fit consent and payment separation | Implemented now | The fit request uses optional contact consent and does not charge a card. Payment requires a separate, deliberate checkout. |
| Paid-seat activation | Implemented now | Returning from Checkout does not activate access. Paid status follows a valid, signed Stripe webhook. |
| Company-system access | Pilot-scoped | Each accepted connection must use separate, attributable, revocable access. An owner's shared primary password is outside the pilot rule. |
| Outbound authority | Pilot-scoped | Routine follow-up may occur only inside a written workflow. Pricing, scope, legal, discount, payment, commitment, and sensitive relationship decisions escalate to the founder. |
| Data fields and retention boundary | Pilot-scoped | The pilot must name the records, fields, purpose, owner, and stop condition before company data is used. |
| Published connector catalog and provider coverage | Planned | Vellward does not currently promise a public list of supported providers, setup times, or always-on connector coverage. |
| Customer-facing retention and export controls | Planned | Provider-specific retention schedules and complete self-service export controls are not claimed as generally available today. |
| Additional roles and broader action authority | Planned | Manager and other roles remain research until the Closer produces evidence and repeated customer demand. |
Access ladder
A pilot should earn authority one bounded step at a time.
Company data
The scope should answer four questions before access is granted.
What may be accessed?
Name the systems, records, and fields. “Everything” is not a valid pilot scope.
Why is it needed?
Tie each permission to a defined workflow purpose and remove access that is not required.
Who owns and can revoke it?
Use company-controlled, attributable access that a named owner can withdraw.
When must work stop?
Define uncertainty, incident, revocation, and consequential-decision stop conditions in advance.
Founder approval boundary
The Closer prepares context. The founder owns the commitment.
A pilot must route these decision classes back to the named company owner.
- Price or discount changes
- Scope or delivery commitments
- Legal or contractual terms
- Payment promises or refunds
- Relationship-sensitive messages
- Any action outside the written authority boundary
Stop rule
No documented owner, contact path, or revocation method means no company-system access.
Before a pilot connects a company system, the scope should name the company owner, Vellward contact, approval path, and revocation path. This is a pilot requirement, not a claim of complete production security certification.