Trust Center
What Deal Vector guarantees — and what it never claims.
The guarantees on this page are not policy statements. Each one is a numbered platform decision, implemented in the database and the product's state machines, and pinned by tests that fail the build if the behavior drifts. The definitions below are rendered from the same code the product uses.
Who says what
Every significant claim in the product carries a badge naming its origin — so a provider assertion is never mistaken for a platform fact.
Buyer requirements and interests originate from the buyer. Potential gaps, observations, and opportunity hypotheses originate from providers. Deal Vector structures, filters, matches, moderates, and presents that information — and the badge of the originator travels with every claim. Badges never mix: an AI summary of a provider assertion is badged as the summary, while the underlying assertion stays the provider's.
- Buyer stated
Stated directly by the buyer organization.
- Vendor asserted
Asserted by the vendor. Deal Vector does not verify or endorse this claim; the buyer decides whether it applies.
- Platform matched
Matched by Deal Vector against explicitly stated buyer criteria and vendor capabilities. Not a diagnosis.
- AI summarized
Condensed by an automated summarizer from the source content. Provenance of the source is preserved.
- Verified evidence
An evidence item reviewed by platform moderation. Verification does not endorse the product.
Decision D-006
Buyer concealment
Buyer identity is concealed from providers at every context level, until the buyer requests an introduction and the provider accepts it.
Before an accepted introduction, a provider sees a buyer only as anonymous context composed from three facts the buyer chooses to share: industry, size band, and region. The buyer's context level — limited, standard, or detailed — controls how rich that context is.
The context level is never a partial reveal of identity.
Name, domain, member names, email addresses, phone numbers, and social identities are excluded at every level. Raising the context level shares richer categories about the organization — never who the organization is.
Identity is disclosed through exactly one path: the buyer requests an introduction and previews the exact information that will be shared, and the provider accepts. No other action on the platform — by the provider, by a moderator, or by the passage of time — reveals who a buyer is.
The same organization, at each context level
- limited
- “A buyer organization (Saudi Arabia)”
- standard
- “Enterprise financial services organization — Saudi Arabia”
- detailed
- “Enterprise financial services organization — Saudi Arabia (10,000–50,000 employees)”
These examples are rendered by the same label function the product uses, which is asserted in lockstep with the database implementation.
A recorded limit, not small print
Concealment prevents the platform from disclosing identity without authorization. It cannot make a buyer unidentifiable if the buyer volunteers identifying detail in free text — a requirement title or a message. Before publishing, a disclosure review shows the buyer exactly what a provider will see and offers a revision; it warns and never blocks, because volunteering context is the buyer's decision. Inferential identification is a residual risk we manage, not one we claim to eliminate.
Decision D-011
Matching neutrality
Deal Vector matches on eligibility and relevance. It does not independently diagnose a buyer's security, and a match endorses nothing.
Eligibility
Hard gates the buyer controls: category stance, the provider types the buyer wants to hear from, blocks, the buyer's evidence standard, and capacity. A provider that fails any gate is absent — not down-ranked, and not told why.
Fit
A deterministic score over only the dimensions the buyer actually specified. A dimension the buyer left unstated neither rewards nor penalizes anyone.
Trust
Verification level and reviewed evidence — always displayed beside fit, never blended into it. A weaker fit never outranks a stronger one because of verification.
A match represents eligibility and relevance, computed against the information and preferences both sides supplied — nothing more. Specifically, a match is:
What a match is not
- Not a vulnerability finding.
- Not a security assessment of the buyer.
- Not a determination that the buyer has a gap. Deal Vector never makes that determination.
- Not an endorsement of a provider assertion.
- Not a recommendation to buy. Ranking reflects overlap with what the buyer stated — the decision is the buyer's.
Match reasons describe overlap with stated needs — and honest gaps in that overlap. A test forbids risk, probability, and vulnerability language in match reasons: matching describes overlap, never diagnosis.
Money cannot buy a match
Nothing a provider pays influences matching. The matching engine structurally carries no price, plan, or tier input — a test inspects the source to keep it that way. Moderation review order never considers provider standing, so review latency is not buyable either.
Decision D-021
Verification boundaries
Verification states what was checked. Nothing more.
What each level actually checked
Unverified
No checks performed. Treat all claims as vendor-asserted.
Identity verified
The submitting person's identity and email domain were confirmed.
Company verified
The organization's legal existence and domain ownership were confirmed.
Evidence verified
At least one evidence item was reviewed by platform moderation.
Enhanced verification
Company and multiple evidence items were reviewed under enhanced diligence.
What verification never means
The first four statements are the single definition held in the codebase — providers read them when they request verification and moderators read the same words before granting one, reproduced here verbatim and addressed to the provider being verified. The last two state, for the public reader, two further things verification never establishes.
- It is not a security certification, and it does not replace your own certifications.
- It is not an approval, endorsement or accreditation by any regulator.
- It is not a statement about the quality of your products or services.
- It is not an assurance that your organization or product resists compromise.
- It is not a guarantee that the provider will deliver successfully on any engagement.
- It is not a general endorsement by Deal Vector — only the specific check named above was performed.
In short: verification establishes that a specific check was performed and passed, and establishes nothing beyond that check. It is not a statement that a provider is technically secure, breach-proof, regulator-approved, certain to deliver successfully, or endorsed by Deal Vector in general.
And because matching is neutral, verification is displayed beside relevance and never inflates it — a provider cannot outrank a more relevant one by being more verified.
Decision D-025
Passive activity opens no channel
Nothing a buyer does while reading — viewing, saving, investigating, marking interest, or dismissing — opens a communication channel.
Viewing, saving, comparing, scoring, shortlisting, investigating, marking interest, dismissing — none of it opens direct commercial access. On a provider-originated insight the provider gets at most an anonymous aggregate count and cannot see which organization acted. On a requirement the buyer published, the provider it invited learns its own match status and nothing more. Neither is a channel.
The same holds across the platform's buyer-side surfaces: comparing responses, scoring them, and shortlisting are buyer-internal at every stage. A provider learns only its own match status — never the buyer's evaluation, scores, or reasoning.
The documented consent boundary is the only mechanism that can open the permitted channel.
The only path to a channel is deliberate: the buyer requests an introduction, which authorizes disclosure of an exact, previewed snapshot; the provider accepts, which executes it. The buyer's request authorizes — the provider's acceptance executes. No passive action sits anywhere on that path, and the consent boundary is documented: unless it explicitly says otherwise, no buyer activity creates commercial access.
Enforced as a graph property
In the delivery state machine, the passive statuses and the access-opening statuses are disjoint sets, and exactly one status — the buyer's own introduction request — has a transition into access. A test walks every status and fails the build if any other path reaches access.
Passive — opens nothing
The only bridge — a deliberate buyer act
Access — requires the bridge, then provider acceptance
Dismissal is terminal: “Not relevant” is final, and a dismissed item cannot come back.
How these guarantees stay true
Decided in the database
Access rules are enforced by row-level security and dedicated procedures in the database, not by the interface. The UI is a convenience; the database is the authority.
One definition, everywhere
This page renders the same constants the product renders — the verification meanings above cannot drift from what a provider or a moderator sees inside the application.
Pinned by tests
The passive/access disjointness, the non-diagnostic match language, the absence of payment inputs, and the label lockstep between application and database are each asserted by tests that fail the build.
These guarantees correspond to platform decisions D-006, D-011, D-021, and D-025 in an append-only decision log. Reversing one would require a new, numbered decision — never a quiet edit. Back to the overview.