Trust & security
Know what happened. Know why. Stay in control.
This page sets out, in plain words, how Valence is built to behave inside your store: who can see what, what has to be true before a customer hears from you, who is in charge of the AI, and what is kept on record. It separates the mechanisms documented today from the safeguards each pilot verifies before they are switched on.
Private preview. No dealership customer records are processed, and no customer messages are sent, through Valence today. Assistant and Autopilot appear on this site as synthetic walkthroughs.
Access
- Applications launched from Hub share one sign-in, with access checked on the server. EquityPulse currently keeps its own sign-in, described below.
- Access is off until it is granted, and several things must agree before anything is visible.
- Every screen knows which store it serves, and switching stores is checked by the server. A manager covering two stores switches in one action and sees only what each store allows; a switch the server refuses is reverted, not fudged.
- Opening an application is checked by the server, once, and recorded, at the moment the door is opened rather than from a menu that was right an hour ago.
- A change to someone’s access takes effect when their session is next checked, not instantly. The pilot security schedule states that timing and verifies it, including for sessions already open and work already running.
Customer consent
- Consent records show where the consent came from and when it was given. A record on file is evidence to review; it does not by itself permit every message.
- No channel is switched on until the dealer and Valence have agreed who is sending, for what purpose and on what permission or documented exception, and the pilot has shown that expiry and stop requests are applied when each message is sent.
- A stop request is recorded against the person and the number, and editing the contact record does not undo it. Before a channel goes live, the pilot shows it also survives imports, queued messages and retries.
Human control
- Autopilot is designed for two modes: a named person approves each draft before it is sent, with the approval recorded, or the store authorizes defined kinds of reply to go out on their own. Either mode needs valid permission to message and a tested sending path before it is switched on, and anything outside the approved scope goes to a person to review.
- Taking over a conversation is designed to stop Autopilot composing and sending in it. A message the carrier has already accepted can’t be recalled, and takeover, queued messages and retries are verified together before live use.
- The stop line reads exactly as follows, so no one mistakes stopping for pausing:
Autopilot is stopping. One message may already have gone out. This conversation is Tomas’s.
- Asking for a person is designed to stop automated replies and pass the conversation to the dealer’s staffed escalation path. Each pilot sets out that path, its hours and what happens when no one is available; this page does not promise an immediate human response.
AI transparency
- Autopilot is designed to identify itself as automated on its first message and whenever a customer asks, with the sender identification and unsubscribe information each message needs. The store approves that wording and the system appends it; it is in place and tested before any customer message is sent.
- Autopilot is designed to refer payment, rate, term, discount and trade-value questions to a person, and it may repeat a recorded list price with the context that price needs. Those limits rely on tested output controls: having no quoting tool does not, on its own, stop generated text from being wrong.
- Assistant is designed to answer from records the person asking is allowed to open, with access checked again when it retrieves and when it acts, and to link the records it used. A generated answer can still be incomplete or wrong: the links are how you check it, not a guarantee. Anything that would change a record waits for an authorized person to confirm it.
Important-action history
- Important changes keep a record of who did what, when, in which store, and what it looked like before.
- Existing entries can’t be edited in ordinary use: new events are added rather than old ones rewritten, so the answer to “what happened with this customer?” is the record rather than a recollection.
- The history still follows an agreed retention schedule, with restricted access and controlled deletion. The pilot security schedule names the events recorded and how long they are kept.
Data handling
- As between Valence and the dealership, the dealership keeps its rights in the records it provides. Individuals keep their privacy rights, and third-party data stays subject to its own terms. Valence uses the records only for the purposes agreed with the dealership.
- Before a pilot starts, its agreement sets out where data is processed, how long it is kept, the export format, return and deletion at the end, backups and any legal holds. Those details are agreed before real data enters the service; this page does not claim a location or a period.
- This website’s privacy policy is the website privacy policy. Product data-processing terms and the approved product provider list are agreed before a pilot processes real dealership or customer information.
Reliability
- We publish no availability commitment and claim none. Any availability or recovery commitment for a pilot is agreed in its signed schedule.
- In an enabled messaging workflow, a message’s delivery status is what the delivery service reported, never assumed. Delivery states in this site’s walkthroughs are illustrative.
- Your store’s clock is the one that counts. A time that doesn’t exist is refused, not moved. The booking path is verified in the pilot before it confirms real appointments.
Stores kept apart
- One store’s customers don’t appear on another store’s screens. This is tested against constructed adversarial data, and each pilot verifies it again for its own release, including exports, background work, support access and any AI retrieval it enables.
- Cost and approved ACV stay store-scoped even when the group reads across its stores. A group view sees stock and velocity; it does not see what a store paid, and group reporting needs its own authorized access.
- One record per store. The product can show a yes/no signal when the same customer identity is already on file at another of your stores. It reads
Known at another Meridian store
with no name, no vehicle and no history from the other store. - Groups. Even a yes/no signal can reveal something about a customer, and stores are often separate legal entities. The signal stays off in a pilot until its purpose, the entities involved, customer notices and any consent or other authority it needs are in place, and its access controls have been verified. Belonging to the same dealer group is not, by itself, that authority. What a group sees across its own stores is performance, stock and velocity compared on one definition; broader visibility is a decision made with legal review, never a promise that the group’s stores share one customer list.
Service providers
- Product providers for hosting, message delivery and any AI service are named in each pilot’s approved provider schedule. No AI provider receives dealership or customer data until its permitted use, retention, locations, access and incident obligations are approved in writing.
- Pilot terms prohibit using dealership or customer data to train shared or general-purpose models, and provider settings and contracts must support that before anything is switched on.
- This website’s own providers are listed on the website service providers page. Each pilot’s terms set out notice and review of changes to its product providers.
Security reporting and privacy contact
- Report a security concern to security@valencedealertech.com. Describe the issue and a safe way to reach you, and please don’t include customer records, passwords or access tokens. Each pilot agreement names its incident contacts and escalation arrangements.
- We hold no third-party security attestation today and don’t claim one.
- Privacy questions go to our Privacy Officer, Evan White: privacy@valencedealertech.com
Quoted lines are taken from the walkthroughs on this site, where Tomas is a salesperson at a synthetic store. Product views use a fictional dealership and synthetic records.
For technical evaluators
Sign-in, permissions, store separation, audit and messaging, in the terms your IT team uses. Open to read.
- Sign-in
- For the applications launched from Hub (Valence CRM, Inventory, Intelligence and the messaging service), sign-in is through an identity provider using OpenID Connect, with sessions held on the server, and passwords are handled by the identity provider rather than by those applications. EquityPulse currently keeps its own sign-in, with passwords stored only as one-way hashes and optional one-time codes, until it joins the same identity provider.
- Roles and permissions
- Roles, permissions, memberships and entitlements are default-deny. Nothing is visible until each of them agrees, and the check runs on the server for every request, not once at sign-in. Revocation is not real-time: a change is picked up when the session is next resolved, and the pilot security schedule states and verifies that timing for open sessions and background work.
- Entering an application
- Opening an application from Hub issues a single-use, server-verified entry pass (a launch token) checked at the destination at the moment it is used and recorded. A pass is verified when it is presented, not when the menu was drawn.
- Application-to-platform calls
- Applications call the platform either as the signed-in person or as a registered service principal with its own narrow scope. There is no anonymous shared credential.
- Per-store separation
- In the platform database, per-store data separation is enforced with row-level security. In the applications it is a query discipline, with every read and write scoped to the store the request is for, and that discipline is what the constructed adversarial tests exercise. No third-party penetration test has been performed, and none is claimed.
- Audit history
- Audit history is append-only in the database: ordinary operations insert entries and never update or delete them, and each entry carries the actor, the time, the store and the prior state. Retention and controlled deletion of audit data follow the schedule approved for each deployment.
- Messaging
- The documented messaging foundation is provider-neutral. Each application, per store and per channel, holds an explicit sending grant; suppression lists (stop requests and complaints) are checked before a send. Send requests carry an idempotency key, so a retried request does not produce a second message. Delivery states are read from the delivery authority: the state you see is the one the delivery service reported, never a guess in between. These foundation controls do not establish that every sender is ready: carrier activation and every applicable permission check are verified for each enabled application and workflow. No carrier is connected and no customer messaging runs through a live pilot today; the staged conversations on this site mark their delivery states as illustrative.
- The Assistant
- The Assistant’s intended access model reads under the caller’s own permissions, re-checked on the server per question. Reading needs no approval; anything it would write is confirmed by a person first. A live answering service, provider terms and end-to-end verification of these safeguards are required before real dealership data is used with it.
- What we don’t claim
- A third-party attestation, an availability figure, a fixed residency, production use at a dealership, or that any of the above makes a breach impossible. We describe the mechanisms and let your people evaluate them.
Questions your evaluators want answered that aren’t here belong in a preview. Bring them, and bring the people who will ask them.
Bring your IT and compliance people.
A preview can be a technical session as easily as a sales one. Bring the people who will have to sign off, and we will go through access, consent, history and store separation with them, question by question.