> ## Documentation Index > Fetch the complete documentation index at: https://docs.promptshields.com/llms.txt > Use this file to discover all available pages before exploring further. # The assessment exchange > Give-to-get: contribute the assessment you had to run anyway, unlock everyone else's. **Built.** Member accounts, contribution intake, normalization and human review, give-to-get unlocking, peer-sharing consent, watchlists and change alerts, and the dated export all exist. The loop closes: contributing earns access, and access is what contributing is for. The directory is useful on day one because it is analyst-seeded. It becomes hard to replicate because **members contribute the vendor assessments they are already required to run**, and consumption is gated on contribution. ## The flywheel Analyst-authored, source-cited profiles in a narrow vertical make the site useful with zero users. No cold-start dependency on contributions that do not exist yet. A member uploads a questionnaire or assessment they completed for their own diligence. It stays member-private by default. Heterogeneous member paperwork is mapped into one shared AI-trust schema — model-assisted, with per-field confidence scoring, and human-reviewed before anything reaches the catalog. Contribution grants entitlement to full reports. The free tier sees summaries. Opt-in shared contributions are anonymized and aggregated into catalog signals. Depth and freshness improve, more buyers arrive, and using the exchange refills it. ## Normalization is the hard part Turning incompatible member paperwork into comparable signal is the defensible core of the exchange, and it is also the single largest piece of work in it. Three distinct problems hide inside the word "normalize": | Problem | What it takes | | - | - | | **The target schema** | Defining the shared AI-trust vocabulary that every contribution maps into — the thing that makes two different questionnaires comparable at all | | **The mapping** | Model-assisted field mapping from arbitrary input formats, with a confidence score attached per field rather than a silent best guess | | **The human loop** | A review and correction queue. Nothing reaches the canonical catalog unreviewed | Treating this as one task is the most likely way to get it wrong, which is why it was built as three. All three now exist. Two details of the third are worth stating, because they are where the guarantee actually lives: * **Nothing reaches catalog signals without a named reviewer.** A contribution is publishable only from a confirmed or corrected review state, and the only function that changes that state also writes the record of who changed it and when. There is no path forward that leaves no attribution. * **Bulk-accept is not switched on.** It exists, but whether any confidence band has earned it is decided from measured accuracy rather than a chosen constant — and today none has. A threshold picked by intuition would make the whole control theatre, so the refusal is the feature. ## What the gate actually counts Built, and the details are where the anti-gaming lives. **Acceptance earns, not upload.** A grant is issued when a contribution has been reviewed and yields at least one usable answer. Tying it to upload would let anyone past the gate with noise, and would make the review queue decorative — so the thing that earns access is the thing that adds value, not the act of sending a file. Three rules close the obvious holes, each enforced in code rather than by inspection: | Rule | Why | | - | - | | One grant per contribution | A single upload cannot be counted twice | | A re-upload of bytes already contributed earns nothing | Otherwise the same file mints credits indefinitely | | A contribution whose every answer was rejected earns nothing | And the member is **told why**, rather than left guessing | Unlocks expire if unspent. The exchange trades in current assessments, and a credit minted long ago keeps nothing fresh — so an unspent grant ages out, while a report already unlocked stays unlocked. **Sharing is never a default.** A contribution is a member's own internal assessment. Sharing it into the exchange is a separate, explicit act about one specific contribution — never bundled into signup, never a consequence of uploading. Consent is recorded with who gave it and when, and withdrawal is recorded the same way, because consent that cannot be shown to have been given is not meaningfully consent. ## What "full report" means At launch there are no peer contributions yet, so the gated full report is the **analyst-seeded full trust profile** — not aggregated peer data. The free-versus-gated boundary is built against the seeded profile, and peer-contributed depth accretes into that report as the exchange fills. Saying so plainly matters: an exchange that implies peer depth it does not yet have spends the credibility it needs to acquire that depth. ## Four audiences, three boundaries Authorization is written against these boundaries, and tested against them: | Audience | Auth | Can do | | - | - | - | | **Public** | None | Ask ATX, browse the directory, read profile summaries, compare two vendors side by side, read the published methodology | | **Member** | Work-email verification | Contribute assessments, unlock full reports, compare those full reports, keep watchlists | | **Vendor** | Ownership proof — DNS or email domain | Claim a profile, publish `vendor_claimed` data, exercise right-to-respond | | **Analyst / admin** | Internal | Curate the canonical catalog, run and publish ratings, moderate | Two verifications that look similar are kept deliberately separate: **contributor verification** establishes that a person is a real practitioner, while **vendor claiming** proves ownership of a company. Different flows, different evidence, different trust levels. Member contributions are private to the member who made them unless explicitly shared, and sharing anonymizes on aggregation. Cross-member isolation is proven by an authorization test suite rather than assumed from the schema. ## What members get out of it * **Full, dated, source-cited due-diligence reports**, exportable for an audit file. Every row carries its source and its verified date: an export that strips provenance is worthless as diligence evidence, because the reader cannot check a single claim in it. * **Watchlists and change alerts** — notification when a vendor's posture *materially* changes, riding on the same change events that drive the [profile change log](/ai-vendor-trust-exchange/trust-profiles#freshness-is-a-product-surface). Immaterial changes stay in the public log and out of every inbox; there is no setting that opts into noise. * **Questionnaire relief** — an answer that already exists, current, instead of another bespoke round trip Why contributing to the exchange never buys a vendor a better score — including your own vendors. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.