# AGENTS Source: https://docs.klariqo.com/AGENTS > **First-time setup**: Customize this file for your project. Prompt the user to customize this file for their project. > For Mintlify product knowledge (components, configuration, writing standards), > install the Mintlify skill: `npx skills add https://mintlify.com/docs` # Documentation project instructions ## About this project * This is a documentation site built on [Mintlify](https://mintlify.com) * Pages are MDX files with YAML frontmatter * Configuration lives in `docs.json` * Use the Mintlify MCP server, `https://mcp.mintlify.com`, to edit content and settings via MCP * Use the Mintlify docs MCP server, `https://www.mintlify.com/docs/mcp`, to query information about using Mintlify via MCP ## Terminology * "Compliance record" or "evidence record" for the signed call record. It is a vCon underneath; say vCon when referring to the standard. * "The dialer you already run" for the customer's existing call system. Klariqo sits on top of it, it does not replace it. * "Verifier" is the public tool that checks a record. "Trusted timestamp" is the RFC 3161 timestamp from DigiCert (an independent authority) that seals when a record existed. DigiCert receives only the fingerprint, never the call content. * "Scorecard" is the customer-configured QA ruleset. "Evidence chain" is the end-to-end flagship story. ## Style preferences * Use active voice and second person ("you") * Keep sentences concise, one idea per sentence * Use sentence case for headings * Bold for UI elements: Click **Settings** * Code formatting for file names, commands, paths, and code references * No em dashes. Use commas, periods, parentheses, or "and" / "but". * Honesty line: describe provenance, evidence, and audit-readiness. Never claim Klariqo makes a customer legally compliant, wins a lawsuit, or automatically handles consent. * All examples are synthetic and clearly labeled. Never use a real call, transcript, phone number, or customer name. ## Content boundaries * Document the product's value, outcomes, and the integration contracts a customer needs (schemas, signatures, setup steps). * Do NOT document internal infrastructure, credentials, hostnames, IP addresses, internal system or table names, or how the platform is built. Connection values a customer needs are delivered in their dashboard, not published here. * Do NOT add "coming soon", "planned", or placeholder pages, notes, or sections. They go stale and force someone to remember to clean them up. Document only what is live. When a feature ships, add its real page then. # AI-call QA Source: https://docs.klariqo.com/call-qa/ai-call-qa How Klariqo reviews each AI voice call against your active scorecard after the call ends, and attaches the QA result to the signed compliance record. AI-call QA reviews Klariqo AI calls after the call ends. For a client with an active scorecard, the QA result is attached to the signed compliance record. The review uses your scorecard. It does not use the AI agent's call prompt as the review rules. ## Scorecard versus prompt The scorecard and the call prompt have different jobs. | Item | Purpose | | ----------- | --------------------------------------------------------- | | Scorecard | The review ruleset used to check the completed call. | | Call prompt | The AI agent's instructions during the live conversation. | That separation matters. The prompt tells the AI agent how to handle the call. The scorecard tells Klariqo how to review what happened after the call. ## What happens after the call Klariqo finishes the AI call and prepares the call record. If the client has an active scorecard, the call is reviewed against the enabled required elements and prohibited claims. QA copies the call's honest classification flags, such as outcome and voicemail state, rather than re-deciding them during review. The QA result is attached to the signed compliance record, so the review travels with the evidence. ## What the result can show The result uses the same QA result structure as other Klariqo-reviewed calls. A call can pass, need review, fail, be not applicable, or temporarily show an error while review is retried. A scored call has an `overall_score` from 0 to 100. An unscored call has `null`, which is not a zero and is excluded from averages. See the operating rules AI calls are reviewed against. Learn how to read status, score, and compliance status. AI-call QA supports evidence, provenance, and audit-readiness. It shows how a call matched your configured scorecard. It does not make you compliant, prove consent by itself, approve your scripts, or replace counsel review. # Human-agent QA Source: https://docs.klariqo.com/call-qa/human-agent-qa How Klariqo reviews human-agent VICIdial calls from the recording against the same scorecard, and attaches QA results to the signed compliance record. Human-agent QA reviews calls handled by your human agents on VICIdial. Klariqo reviews those calls from the call recordings. The same scorecard QA and sentiment analysis apply. This lets you use one operating ruleset across AI calls and human-agent calls. Setting this up? See [Connect VICIdial](/dialer-integrations/connect-vicidial). It needs only recording access, not the SIP voice setup. ## How human-agent QA works The review starts from the customer's VICIdial call recording. Klariqo transcribes the recording and attributes turns to the agent or the customer. The call is reviewed against your configured required elements and prohibited claims. Sentiment analysis is attached alongside the QA result. The QA result and sentiment become part of the signed compliance record. ## Role attribution caveat Role attribution is inferred from the audio. It identifies which speaker is the agent and which speaker is the customer, but it is not perfect. Attribution is less certain on a single-channel, mono recording than on a dual-channel recording. When a turn cannot be confidently attributed, the record flags it as `role_unattributed`. Do not treat role attribution as perfect. Review flagged turns when attribution confidence matters for your workflow. ## Same rules across AI and human calls Human-agent QA uses the same scorecard structure as AI-call QA. Required elements, prohibited claims, critical checks, and enabled checks work the same way. That gives you one review language for your operating rules, whether the call was handled by Klariqo AI or by a human agent on your dialer. See the operating rules human-agent calls are reviewed against. Learn how to read status, score, and compliance status. Human-agent QA supports evidence, provenance, and audit-readiness. It shows how a call matched your configured scorecard. It does not make you compliant, prove consent by itself, approve your scripts, or replace counsel review. # Call QA Source: https://docs.klariqo.com/call-qa/overview How Klariqo reviews every in-scope call for quality and compliance against your own scorecard, on AI voice calls and human-agent VICIdial calls alike. Klariqo reviews your calls for quality and compliance against rules you configure. It runs on Klariqo AI calls and on human-agent calls on your dialer. The review is attached to the signed compliance record, so the result travels with the evidence. ## What gets reviewed Every in-scope call is reviewed, not a sample. "Reviewed" means each call is checked against your scorecard. It does not mean every call gets a numeric score: some calls are not applicable, for example a voicemail or a call with no real engagement. ## How it works Your required elements (what an agent should do) and prohibited claims (what they must not say), with the checks that matter most marked critical. See [scorecards](/call-qa/scorecards). After the call, it is reviewed against your scorecard. AI calls and human-agent calls are both covered. The status, score, a one-line summary, and the supporting evidence are attached to the call's signed compliance record. See [QA results](/call-qa/qa-results). ## What you get The rules each call is reviewed against, configured by you. How to read a status, a score, and the evidence behind it. A scorecard is your operating rule set, not a Klariqo legal template. QA tells you whether a call matched your rules. It is not a legal compliance judgment, and a passing score does not make a call lawful. See [the evidence boundary](/compliance-records/evidence-boundary). # QA results Source: https://docs.klariqo.com/call-qa/qa-results How to read a Klariqo QA result: call status, overall score from 0 to 100, compliance status, and what unscored calls like voicemail mean for reporting. A QA result is the review outcome for a call covered by an active scorecard. It tells you the call status, the overall score when the call can be scored, and the compliance status attached to the signed record. ## Result status A QA result can use these status values: | Status | Meaning | | ---------------- | ------------------------------------------------------------------- | | `pass` | The call passed the scorecard review. | | `needs_review` | The call needs review. | | `fail` | The call failed the scorecard review. | | `not_applicable` | The call could not be graded, such as voicemail or no engagement. | | `error` | A transient judge failure occurred, and the review is auto-retried. | ## Scores `overall_score` is a number from 0 to 100 when the call is scored. `null` means unscored. It is not a zero. Unscored results are excluded from averages. Do not treat a null score as a failed score or a perfect score. It means the call did not receive a numeric score. ## Compliance status The compliance status is separate from the result status. It can be: | Compliance status | Meaning | | ----------------- | ----------------------------- | | `pass` | The compliance review passed. | | `fail` | The compliance review failed. | | `not_evaluated` | The call was unscored. | `not_evaluated` is used when a result is unscored. ## Not applicable and error `not_applicable` means the call could not be graded. This happens for voicemail, or when there is no engagement, defined as fewer than two caller turns. The judge is not called at all. `error` means a transient judge failure occurred. The review is auto-retried. ## What 100% QA means "100% QA" means every in-scope call is reviewed. It does not mean every call receives a numeric score. Some calls are reviewed and then marked `not_applicable`. Some may temporarily show `error` while the review is retried. Those cases are not the same as a scored call with a zero. See the operating rules each call is reviewed against. Check the signed record that carries the QA result. QA results are evidence and provenance, not a legal judgment. They show how a call matched your configured scorecard. They do not make you compliant, prove consent, or replace review by your own counsel. # Scorecards Source: https://docs.klariqo.com/call-qa/scorecards How Klariqo scorecards define the required elements and prohibited claims each call is reviewed against, with critical checks that gate compliance status. A scorecard is the operating rule set Klariqo uses to review your calls. You define what should happen on a call, what must not be said, which checks are critical, and which checks are enabled. Scorecards apply to Klariqo AI calls and to human-agent calls on your VICIdial dialer. ## What a scorecard contains Required elements are the things an agent should do on the call. Each required element has a key, a label, a critical flag, and an enabled flag. Prohibited claims are the things an agent must not say. Each prohibited claim has a key, a label, a critical flag, and an enabled flag. A critical check marks a serious failure if that check fails. Disabled checks are turned off and excluded from results. ## Required elements Required elements define what the call should include. They are stored as: ```json theme={null} [ { "key": "synthetic_required_element", "label": "Synthetic required element", "critical": true, "enabled": true } ] ``` This example is synthetic. Your scorecard should reflect your own scripts, disclosures, and operating rules. ## Prohibited claims Prohibited claims define what the call should not include. They are stored as: ```json theme={null} [ { "key": "synthetic_prohibited_claim", "label": "Synthetic prohibited claim", "critical": true, "enabled": true } ] ``` This example is synthetic. It is only here to show the field shape. ## How scoring uses a scorecard Klariqo reviews enabled required elements and enabled prohibited claims. Each category carries a score, and those category scores roll up into the overall score for the call. Disabled checks are excluded from results. They do not affect the category score or the overall score. Learn how to read a status, score, and compliance status. See how QA joins the signed compliance record. Scorecards are customer-configured operating rules, not Klariqo legal templates. QA shows whether a call matched your rules. It does not make you compliant, prove consent, or replace review by your own counsel. # Fetch the signed vCon Source: https://docs.klariqo.com/compliance-export-webhooks/fetch-the-signed-vcon Retrieve the signed compliance record from the short-lived link in a compliance export webhook, then verify its JWS signature before you store it. A webhook delivers a pointer, not the record itself. To get the record, fetch it from the download URL in the event. The URL is short-lived and tied to that one record. ## Fetch and verify Take the download URL from the event envelope you received. Fetch the URL promptly. It returns the signed vCon, the full compliance record. Check the signature, the same way the public verifier does, and confirm the recording's SHA-512 content hash in the record. See [verify a vCon](/compliance-records/verify-a-vcon). ## Notes * The URL is short-lived. Fetch it promptly and store the record you retrieved, not the URL. * The URL is bound to one record. It will not return any other record. How to check a signed record's integrity. Confirm the webhook delivery itself. # Compliance export webhooks Source: https://docs.klariqo.com/compliance-export-webhooks/overview Push every finalized Klariqo compliance record to your own system with a signed webhook the moment it is ready, and fetch the signed vCon from the link. When a compliance record is final, Klariqo can push it to your system with a signed webhook. You receive a pointer to the signed record and fetch the record itself from a short-lived link. This lets you keep your own copy of every record, in your own systems, automatically. ## How it works In your dashboard, give Klariqo an HTTPS URL to deliver to. You get a signing secret for that endpoint. Klariqo sends a verification challenge, and your endpoint echoes it back. An endpoint can only receive real records after it is verified. When a record is final, Klariqo sends a signed `compliance_record.ready` event to your endpoint. Verify the signature, then fetch the signed vCon from the link in the event. ## What the delivery looks like The webhook carries a pointer, not the full record inline: an envelope with the call metadata and an expiring download URL for the signed vCon. Every delivery is signed using the Standard Webhooks scheme, so you can confirm it came from Klariqo before you trust it. Delivery is forward-only from the moment you enable an endpoint, at least once, with no ordering guarantee, so dedupe by the event id. Add a URL, get your secret, and pass the verification handshake. Confirm a delivery genuinely came from Klariqo. The shape of the delivered event. Retrieve and verify the record itself. Exporting records gives you your own copy of the evidence. It does not change your compliance obligations. You remain responsible for how you store, retain, and act on the records you receive. # Compliance record envelope Source: https://docs.klariqo.com/compliance-export-webhooks/record-envelope The shape of the compliance_record.ready event Klariqo sends when a signed record is ready: call metadata, event id, and the expiring signed vCon URL. A compliance export webhook sends a pointer to a signed compliance record. It does not send the full signed vCon inline. The event type is `compliance_record.ready`. It means a finalized signed compliance record is ready to fetch. ## What the envelope contains The event type is `compliance_record.ready`. The envelope includes call metadata so your system can route and store the export. The envelope includes an expiring download URL for the signed vCon. The download URL is bound to the record content hash. ## Synthetic example This example is synthetic. It shows the public shape of a pointer export, not a real call or customer record. ```json theme={null} { "type": "compliance_record.ready", "call": { "id": "synthetic-call-123", "started_at": "2026-06-27T12:00:00Z" }, "record": { "format": "vcon", "content_hash": "sha512-synthetic-content-hash", "download_url": "https://example.com/synthetic-expiring-vcon-download" } } ``` The `download_url` is short-lived. Fetch the signed vCon after you verify the webhook signature, then store the record according to your own retention policy. Do not treat the webhook body as the signed compliance record. The signed vCon is fetched from the record download URL. ## Delivery behavior Compliance record exports are forward-only from endpoint enablement. Klariqo does not promise historical backfill for records created before the endpoint was enabled. Deliveries are at least once. Your endpoint may receive the same delivery more than once, so dedupe by the delivery id. Klariqo does not guarantee ordering between deliveries. ## How to handle an event Verify the Standard Webhooks signature against the raw request body. Check whether you have already processed the delivery id. Confirm the event type is `compliance_record.ready`. Use the expiring download URL to fetch the signed compliance record. Store the signed vCon in your own system according to your retention and access rules. Verify a webhook before processing the envelope. Retrieve the signed record from the pointer. Exported records support evidence, provenance, and audit-readiness. They do not make you compliant, prove consent by themselves, or replace your retention policy and counsel review. # Set up an endpoint Source: https://docs.klariqo.com/compliance-export-webhooks/set-up-an-endpoint Register a webhook endpoint in the Klariqo dashboard, receive your signing secret, and pass the verification challenge before real records are delivered. An endpoint is the HTTPS URL where Klariqo delivers signed records. You add it in your dashboard, prove you control it, then enable it. ## Add the endpoint In your dashboard, under Compliance export, add an HTTPS URL. Klariqo generates a signing secret for that endpoint. Copy the secret now; it is shown only once. Klariqo sends a verification request carrying a challenge. Your endpoint must echo the challenge back, either in the response body or in a response header. This proves you control the URL. Once the endpoint is verified, enable it. From that point, newly finalized records are delivered to it. ## Requirements * HTTPS only, on a public URL that Klariqo can reach. * Respond with a 2xx quickly. Acknowledge first, then do any heavy processing. * Keep the signing secret safe. You need it to verify every delivery. ## Rotating the secret You can rotate the signing secret. During a rotation, the previous secret stays valid for a short window. Deliveries are signed with both the old and the new secret, so you can update your endpoint within the window without missing a record. Confirm a delivery genuinely came from Klariqo. The shape of the event you receive. # Verify webhook signatures Source: https://docs.klariqo.com/compliance-export-webhooks/verify-signatures How to verify a Klariqo compliance export webhook using the Standard Webhooks scheme and your endpoint secret before you trust or store the delivery. Every compliance export webhook is signed. Verify the signature before you process the event, fetch the signed vCon, or store anything from the delivery. Klariqo uses the Standard Webhooks signing format. ## Headers Each delivery includes these headers: | Header | Meaning | | ------------------- | -------------------------------------------------- | | `webhook-id` | The unique delivery id used in the signed content. | | `webhook-timestamp` | The timestamp used in the signed content. | | `webhook-signature` | The signature value, formatted as `v1,`. | Your endpoint also receives a signing secret for this webhook endpoint. The secret is formatted as `whsec_`. ## What is signed The signed content is: ```text theme={null} id.timestamp.body ``` Where: | Part | Source | | ----------- | ------------------------------------------------ | | `id` | The `webhook-id` header. | | `timestamp` | The `webhook-timestamp` header. | | `body` | The raw request body exactly as Klariqo sent it. | Verify against the raw request body. Do not parse JSON and then stringify it again before verification. Even a harmless formatting change can make the signature check fail. ## Verification steps Read `webhook-id`, `webhook-timestamp`, and `webhook-signature` from the request. Reject requests with a large timestamp skew. This helps prevent old signed deliveries from being replayed later. Build the signed content from the header id, header timestamp, and the raw request body. Verify the `v1,` signature with the endpoint signing secret. Only process the event after the signature passes. ## What to reject Reject the request if: * A required signature header is missing. * `webhook-signature` is not in the `v1,` format. * The timestamp has a large skew. * The signature does not verify against the raw body. * The same delivery id has already been processed. ## After verification After the signature passes, process the event as a pointer to the compliance record. The webhook payload does not contain the full signed vCon inline. It contains an envelope and an expiring download URL for the signed vCon. See how compliance record exports work. Understand the event payload you receive. Signature verification proves delivery integrity for the webhook request. It is not a legal judgment. Exported records support evidence, provenance, and audit-readiness, but you remain responsible for scripts, consent, retention, storage, and counsel review. # The evidence boundary Source: https://docs.klariqo.com/compliance-records/evidence-boundary What a Klariqo compliance record can prove and what it cannot: evidence and provenance of a call, not a legal compliance judgment or consent decision. A Klariqo compliance record is strong evidence. It is not a legal verdict. Being precise about that line is part of the product, and it is what makes the evidence credible in the first place. ## What a record can show * The record's contents, the transcript, a reference to the recording, the QA result, and sentiment, exactly as they were signed. * That the record was not altered since it was signed. * That it was signed by Klariqo's published key (self-asserted). * That an independent authority (DigiCert) timestamped the record's fingerprint at a point in time. ## What a record does not do * It does not make you compliant. Compliance depends on your scripts, your disclosures, your consent practices, and the law that applies to you. * It does not, by itself, prove that a call was lawful or that consent was valid. * It is not legal advice and not a substitute for your own counsel. * Scorecard presets are starter examples for your own review, not legal templates and not a guarantee of any outcome. ## Where your responsibility sits You own your scripts, your consent practices, your retention policy, and review by your counsel. Klariqo gives you a tamper-evident, independently verifiable record of what happened on the call. The compliance program around it is yours. See exactly what the record captures, end to end. Check any record's integrity yourself. # The evidence chain Source: https://docs.klariqo.com/compliance-records/evidence-chain How a phone call becomes a Klariqo compliance record step by step: recording, content hash, transcript, QA analysis, JWS signature, and a trusted timestamp. A call happens today. Months later, someone asks three questions about it: what was actually said, can you prove the record was not edited, and can an independent party confirm the record existed. Klariqo produces a record that answers all three. This page walks the chain end to end. It runs the same way for an AI call and for a human-agent call, on the dialer you already run. ## The chain, step by step The recording and transcript of the call are captured, whether the call was handled by a Klariqo AI agent or by a human agent on your dialer. A SHA-512 content hash is computed over the recording. It is a fingerprint: change a single byte of the audio and the hash changes completely. This is what later proves the audio was not swapped or edited. The call is assembled into a vCon, the IETF-track standard container for a conversation record (the parties, the dialog, and analysis). See [what is a vCon](/compliance-records/what-is-a-vcon). The vCon is signed with a JWS signature (RS256), carrying Klariqo's signing certificate. The signature is tamper-evident: any later edit to the record breaks it. See [signed vCons](/compliance-records/signed-vcons). The call's quality and compliance review (pass, needs review, or fail) and its sentiment are attached as signed analysis blocks inside the record. See [call QA](/call-qa/overview). A trusted timestamp (RFC 3161) is obtained from DigiCert, a global certificate authority Klariqo does not control. It stamps the record's fingerprint with the time, so anyone can later confirm this exact record existed at that moment and was not backdated. DigiCert receives only the fingerprint, never the transcript, audio, phone numbers, or QA content. See [verify the timestamp](/compliance-records/verify-the-timestamp). The signed record can be checked in the public verifier, which reports whether it is valid, altered, unsigned, or not issued by Klariqo. You do not have to take our word for it. See [verify a vCon](/compliance-records/verify-a-vcon). When the record is final, a signed webhook pushes a pointer to your system, and you fetch the signed vCon from a short-lived link. See [compliance export webhooks](/compliance-export-webhooks/overview). ## What this gives you An audit-ready, tamper-evident, independently verifiable record of every in-scope call, produced automatically and sitting on top of the dialer you already run. When an auditor, a carrier, or a client asks "what happened on this call," you hand them a record that proves its own integrity. This is evidence and provenance, not a legal judgment. A signed, timestamped record proves what the record contains and that it was not altered after signing. It does not by itself prove that a call legally occurred, and it does not make you compliant. You remain responsible for your scripts, your consent practices, your retention policy, and review by your own counsel. See [the evidence boundary](/compliance-records/evidence-boundary). ## See the whole record Every claim above maps to a part of the record you can inspect and verify yourself. The standard container that holds the call record. How the signature makes the record tamper-evident. Check any record yourself in the public verifier. Confirm the DigiCert trusted timestamp yourself. # Compliance records Source: https://docs.klariqo.com/compliance-records/overview What a Klariqo compliance record is, what it contains, and why the signed, timestamped, independently verifiable record is trustworthy without trusting us. Every in-scope call on Klariqo produces a compliance record: a signed, independently verifiable account of the call that sits on top of the dialer you already run. This section explains what is in that record and why you can trust it. If you read one page, read [the evidence chain](/compliance-records/evidence-chain). It walks a call from audio to verified record in one place. ## What a record contains Who was on the call and the conversation itself: the transcript, a reference to the recording, and the SHA-512 content hash that fingerprints that recording. Signed analysis attached to the record: the quality and compliance review of the call, and its sentiment. A JWS signature over the whole record, carrying Klariqo's signing certificate, so any later change is detectable. You can also bind selected fields from your dialer into the signed record, such as a consent reference or the disposition. See [add your dialer's fields](/dialer-integrations/field-enrichment). ## Why you can trust it Tamper-evident. Any edit after signing breaks the signature. An independent trusted timestamp from DigiCert proves the record existed at a point in time, without seeing its contents. You can check any record yourself, no trust in Klariqo required. ## The standard underneath Klariqo records are vCons, the IETF-track standard for a conversation record. Klariqo issues a signed call record; it does not own the standard. See [what is a vCon](/compliance-records/what-is-a-vcon). A compliance record is evidence and provenance, not a legal judgment. It proves what the record contains and that it was not altered. It does not make you compliant, and you remain responsible for your scripts, consent, retention, and counsel review. See [the evidence boundary](/compliance-records/evidence-boundary). # Signed vCons Source: https://docs.klariqo.com/compliance-records/signed-vcons How a JWS RS256 signature over a Klariqo vCon makes the record tamper-evident, what integrity and self-asserted origin prove, and what they do not prove. Every Klariqo compliance record is signed so that any change to it is detectable. This page explains what the signature is, and what it does and does not prove. ## How the signature works A SHA-512 content hash is computed over the recording and stored in the record. It ties the record to that exact audio. A JWS signature (RS256) is computed over the whole record. The signature carries Klariqo's signing certificate, so a verifier has what it needs to check it. Any later change to the record, even a single character, makes the signature fail verification. There is no silent edit. ## What the signature proves * **Integrity.** The record is exactly what was signed, unchanged. This is the strong, independent guarantee. * **Origin, self-asserted.** It was signed by Klariqo's published key. Self-asserted means we publish our key and you can check a record was signed by it. Klariqo is not a certificate authority, and the signature does not chain to a government or third-party root. ## What it does not prove A valid signature proves the record's integrity and origin. It is not a legal judgment. It does not by itself make a call lawful, prove consent, or make you compliant. See [the evidence boundary](/compliance-records/evidence-boundary). ## Verify it yourself Paste or upload any record and check the signature in your browser. # Verify a vCon Source: https://docs.klariqo.com/compliance-records/verify-a-vcon Verify any Klariqo compliance record yourself in seconds: check the JWS signature, content hash, and trusted timestamp, right in your browser. A compliance record is only as good as your ability to check it. You do not have to take Klariqo's word that a record is genuine. Any record can be verified independently in the public verifier, which runs entirely in your browser. ## Verify a record Go to [klariqo.com/vcon](https://klariqo.com/vcon/). Nothing is uploaded to a server. The check runs locally in your browser. Paste the record, or upload the `.vcon.json` file, or try the built-in sample to see a valid result first. The verifier tells you whether the signature is valid, whether the record was altered, and whether it was signed by Klariqo's key. ## What the results mean | Result | What it means | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Signature valid, signed by Klariqo's key | The record has not been altered since signing, and it was signed by Klariqo's published key. | | Signature valid, not Klariqo's key | The signature is valid, but the signer is not Klariqo. Klariqo makes no claim about that record. | | Invalid signature | The record was altered after signing, or its signature does not match the certificate. A genuine, unaltered record passes this check. | | No signature present | The record carries no signature to verify. | | Not a vCon | The file is not a vCon record. | | Encrypted | The record is encrypted and cannot be read or verified without the decryption key. | ## What "signed by Klariqo's key" means Klariqo publishes its signing key, and the verifier confirms a record was signed by that key. This is self-asserted: we vouch for our own key, we are not a certificate authority. The strong, independent guarantee is the tamper check. A valid signature proves the record's contents are exactly what was signed, byte for byte, including the SHA-512 fingerprint of the recording. For an independent attestation that the record existed at a point in time, checked against DigiCert (a global trust authority Klariqo does not control), see [verify the timestamp](/compliance-records/verify-the-timestamp). Verifying a record confirms its integrity. It is not a legal judgment. A valid record proves what the record contains and that it was not altered. It does not by itself make a call lawful or make you compliant. See [the evidence boundary](/compliance-records/evidence-boundary). How the signature makes a record tamper-evident. Where verification fits in the full story. # Verify a record's trusted timestamp Source: https://docs.klariqo.com/compliance-records/verify-the-timestamp Confirm a Klariqo compliance record existed at a point in time, checked against DigiCert, a global trust authority Klariqo does not control. No account, no login. The [signature check](/compliance-records/verify-a-vcon) proves a record was not altered since Klariqo signed it. The trusted timestamp adds an independent, outside proof of time: it shows this exact record already existed at a specific moment, attested by DigiCert, a global certificate authority that Klariqo does not run. That makes later backdating or silent replacement detectable. The timestamp uses RFC 3161, the same standard behind the timestamps on digitally signed PDFs and e-signatures. When a record is signed, Klariqo sends a SHA-256 fingerprint of it to DigiCert's timestamp authority, which returns a signed token that says "this exact fingerprint existed at this time." No transcript, phone number, name, or recording is sent to DigiCert, only the fingerprint. ## What you need Every signed record can be downloaded as an evidence bundle (a `.zip`) that contains everything needed to check it, with nothing from Klariqo required at verification time: * `.vcon.json` the signed record itself * `.tsr` the DigiCert timestamp token * `digicert-root.pem` DigiCert's public root certificate, so the check runs offline * `VERIFY-THIS-RECORD.txt` these instructions The trust comes from DigiCert, whose root is already in every operating system and browser. You can use the copy in the bundle, or your own system's trust store, or confirm the root matches DigiCert's published Trusted Root G4. The result is the same. ## Verify it yourself You need OpenSSL, which is free and standard. It is already on Mac and Linux. On Windows it is included in Git Bash (part of the free Git for Windows). Unzip the bundle, then open a terminal in that folder. On Windows, use Git Bash (not PowerShell), where OpenSSL is already available. Run one line (substitute the record's actual filenames): ```bash theme={null} openssl ts -verify -token_in -data record.vcon.json -in record.tsr -CAfile digicert-root.pem ``` A genuine record prints exactly: ```text theme={null} Verification: OK ``` That confirms DigiCert, not Klariqo, attests this exact record existed at the stamped time and has not been altered. Change one byte of the record and the check fails. To see the exact moment DigiCert sealed the record: ```bash theme={null} openssl ts -reply -token_in -in record.tsr -text ``` Look for the `Time stamp:` line. ## What this proves | Check | What it tells you | | ------------------------------------- | ------------------------------------------------------------------- | | `Verification: OK` | This exact record, unchanged, was timestamped by DigiCert. | | The stamped time | The record existed no later than that moment, per DigiCert's clock. | | Checked against DigiCert, not Klariqo | The proof does not depend on trusting Klariqo. | Because a record is timestamped within moments of the call, a matching timestamp shows the record existed right after the call and has not changed since, so it could not have been created or edited later. A trusted timestamp proves integrity and timing: that this exact record existed at that moment and was not altered. It does not prove a conversation took place, does not prove consent, and does not make a call lawful or make you compliant. The record itself (recording and transcript) is the evidence of content, and final legal admissibility is your counsel's determination. See [the evidence boundary](/compliance-records/evidence-boundary). Check the signature and tamper-evidence of a record. See how a call becomes a signed, timestamped record end to end. # What is a vCon Source: https://docs.klariqo.com/compliance-records/what-is-a-vcon How the IETF vCon conversation-record format turns a phone call into a structured, signed compliance record with parties, dialog, analysis, and attachments. A vCon is a structured conversation record. It gives a call a standard shape: who participated, what happened in the dialog, and what analysis was attached afterward. Klariqo uses vCons as the container for compliance records. We issue signed vCons for calls covered by an active scorecard. We do not own the vCon standard. ## Current IETF status vCon is an IETF-track conversation-record format under the IETF Virtualized Conversations working group. As of June 27, 2026, the core vCon document is an active working-group Internet-Draft, not a published RFC. That means vCon is work in progress in the IETF process. It should not be described as a ratified RFC standard yet. The vCon effort is associated with the IETF vCon working group, Jeff Pulver, and conserver.io. ## What a vCon contains The participants in the conversation. In a call record, this is the structured place for the people or systems involved in the call. The conversation itself. In a Klariqo compliance record, the dialog includes the transcript, a reference to the recording, and a SHA-512 content hash that fingerprints the recording. Structured review data attached to the conversation. Klariqo records can include transcript analysis, quality and compliance results, sentiment, and telemetry. Klariqo signs the vCon with a JWS signature (RS256) that carries Klariqo's signing certificate. This makes later edits detectable. ## Klariqo's role Klariqo is the issuer of the signed call record. The record uses the vCon format underneath, then adds Klariqo's signature and analysis blocks. That distinction matters. vCon is the conversation-record format. Klariqo's compliance record is a signed vCon issued by Klariqo for an in-scope call. See how a call becomes a signed, timestamped, verifiable record. Learn how the signature makes a record tamper-evident. ## Why this matters A vCon gives the call one portable record instead of scattered artifacts. The transcript, recording reference, recording fingerprint, QA result, sentiment, and signature travel together. That gives you evidence and provenance in one place. It does not make you compliant by itself. You remain responsible for your scripts, consent practices, retention policy, and counsel review. # Connect VICIdial Source: https://docs.klariqo.com/dialer-integrations/connect-vicidial Connect Klariqo to your VICIdial for compliance review and call QA using recording access only, with no SIP setup, agent changes, or dialer downtime. Most customers connect VICIdial for **compliance and QA**: Klariqo reviews your calls from their recordings, after the call, and turns each one into a signed, independently verifiable compliance record. This is the default way to connect, and the lightest. Klariqo reads your recordings after the call. It does not register as a SIP agent, place calls, or transfer calls. Want Klariqo's **AI voice agent** to handle calls on your dialer, as well or instead? That is a separate, heavier setup. See [Connect VICIdial for voice AI](/dialer-integrations/connect-vicidial-voice). ## What you do not need Connecting for compliance and QA skips the entire voice setup: * No SIP phone extension. * No SIP port (5060) whitelisting. * No remote agent. * No transfer dialplan. * No server restart or SIP reload. ## What Klariqo needs Klariqo reads your call recordings through VICIdial's built-in non-agent API. To set that up, you provide: The web address of your VICIdial admin and API, for example `https://dialer.yourcompany.com`. A VICIdial user with API access and permission to view reports and lead information. Klariqo uses this account to list recordings, retrieve them, and read each call's caller number and direction for the record. Klariqo uses read functions only, and no write access is needed: * `agent_stats_export` and `recording_lookup` to find and fetch recordings. * `lead_field_info` and `lead_all_info` to read caller and lead fields. These need the user's "GET LEAD INFO" permission. * `phone_number_log` to confirm whether each call was inbound or outbound. Klariqo must be able to reach your VICIdial API and download the recording URLs it returns. If your system restricts API or recording access by IP, allow the Klariqo IP we give you during setup. Confirm that these calls were lawfully recorded and that you are authorized to submit them for review. Give the agent IDs you want reviewed. If you leave this open, Klariqo reviews the agents that were active in each review window. Before any review starts, use the **Test connection** button in your Klariqo dashboard. It checks that the API authenticates, that both read functions work, and that a recording actually downloads, and it shows exactly which step failed if anything is blocked. ## What each record captures Every reviewed call becomes a record that carries the caller's phone number, the agent who handled it, the timestamp, the duration, and the call direction. Klariqo reads these values directly from your dialer's own call logs, and attaches them to the QA score and the signed record. Direction is resolved per call, never assumed, because it affects consent obligations: * **Inbound** calls are positively confirmed from your inbound call log. * **Outbound** calls are positively confirmed when your VICIdial has an index on the `phone_number` column of its call-log tables. This is a one-line change your database administrator can make, and it is [recommended by VICIdial's own documentation](https://www.vicidial.org/docs/NON-AGENT_API.txt). Without it, on high-volume systems Klariqo marks an unconfirmed call `unknown` rather than guessing, so the record stays honest. If a line carries only one direction (for example an inbound-only queue), tell us during setup and Klariqo labels it accordingly. If a line carries both, add the index above for full outbound confirmation. ## What you get How Klariqo reviews human-agent calls against your scorecard. How each reviewed call becomes a signed, timestamped record. Bind the lead fields you choose, such as a consent reference or disposition, into each signed record. Klariqo reviews recordings you provide and warrant you have the right to review. QA and signed records support evidence, provenance, and audit-readiness. They do not make you compliant, do not prove consent by themselves, and do not replace review by your counsel. # Connect VICIdial for voice AI Source: https://docs.klariqo.com/dialer-integrations/connect-vicidial-voice Run Klariqo's AI voice agent on your VICIdial as a remote SIP agent: a heavier customer-side setup your VICIdial administrator configures end to end. Klariqo connects to your VICIdial as a remote SIP agent so its AI voice agent can handle calls. It does not replace your dialer. The setup is the same as adding a new remote SIP phone and agent. Only want Klariqo to review your calls for QA and compliance, with no AI on your calls? That is the default, lighter path. See [Connect VICIdial](/dialer-integrations/connect-vicidial). It needs only recording access, no SIP. ## What Klariqo sends you Keep these open while you work through the setup. | Field | Value | | ------------------ | -------------------- | | SIP extension name | `klariqo-ai` | | SIP password | Sent to you securely | | Klariqo server IP | `35.232.23.234` | | Number of lines | `10` | These are the standard values. You can use your own extension name, dial plan number, and agent IDs. Just share your chosen values with Klariqo so we match our configuration. ## Step 1: Create a phone extension In your VICIdial admin panel, go to **Admin > Phones > Add a New Phone**, and fill in: | Field | What to enter | | --------------------- | ------------------------------------------------------------------------ | | Phone Extension | `klariqo-ai`, or the exact value Klariqo gave you. | | Dial Plan Number | Any unused number, like `800` or `8400`. Write it down. | | Server IP | Select your VICIdial server from the dropdown. | | Protocol | `SIP` | | Registration Password | The password Klariqo gave you. Use it exactly, with no extra characters. | | Active | `Y` | | Voicemail | Leave empty or set to `N`. | Click **Submit**. ## Step 2: Allow Klariqo's server to connect Klariqo connects from a single IP, `35.232.23.234`. The easiest way to allow it is VICIdial's built-in IP Lists. Go to **Admin > System Settings**, set **Allow IP Lists** to `1`, and save. Go to **Admin > Users**, open your admin user, set **Modify IP Lists** to `1`, and save. Go to **Admin > IP Lists > Add An IP List**. Create a list (for example, named `ViciWhite`) and add `35.232.23.234` to it. Submit. Give it about 60 seconds to sync, then Klariqo can register. If your VICIdial runs at a cloud provider (AWS, GCP, Hetzner, DigitalOcean, Linode, and others), the provider runs its own firewall above the server's. Even with the server firewall open, the cloud firewall can drop our packets first. This is the single most common reason a setup stalls. Add an inbound rule allowing UDP and TCP on port 5060 (or your custom SIP port) from `35.232.23.234`. To check it is open, run `tcpdump -ni any port 5060` on your VICIdial machine while Klariqo tries to connect. If you see packets from `35.232.23.234`, the cloud firewall is open. If you see none, it is still blocking. If you do not manage the server yourself, send the IP `35.232.23.234` to whoever does and ask them to whitelist it and reload SIP, including the cloud-provider firewall. ## Step 3: Create a remote agent This tells VICIdial to send calls to the extension you created. Go to **Admin > Remote Agents > Add a New Remote Agent**, and fill in: | Field | What to enter | | ------------------ | ---------------------------------------- | | Remote Agent ID | Any number, like `1001`. | | User (Agent) | A name for this agent, like `klariqo`. | | External Extension | The dial plan number from Step 1. | | Number of Lines | `10`, or whatever Klariqo told you. | | Campaign | The campaign you want Klariqo to handle. | | Status | `ACTIVE` | Click **Submit**. If you add a second remote agent later for another campaign, give it a User ID range that does not overlap the first. VICIdial reserves a block of consecutive User IDs per agent, and an overlap makes registration fail silently after a couple of minutes. ## Step 4: Submit your configuration Submit your SIP details from your Klariqo dashboard, under [Settings, Dialer Setup](https://app.klariqo.com/settings?tab=dialer). This is where every live client manages their VICIdial connection. You will enter: * Your VICIdial server IP and SIP port. The default is `5060`, but many installs use a custom port. Confirm yours with `asterisk -rx "sip show settings" | grep -i bindport`. * The phone extension name (`klariqo-ai`) and registration password from Step 1. * An optional transfer phone number or VICIdial extension. * Confirmation that `35.232.23.234` is whitelisted on your server. Registration happens automatically once you save. Keep `35.232.23.234` whitelisted. ## Step 5: Set up transfers Optional for inbound-only use, required for outbound campaigns where Klariqo transfers qualified leads to a human closer. VICIdial's **Carriers** section is the canonical place to add transfer dialplan entries. It writes to your Asterisk config and reloads automatically, with no SSH or server restart. Go to **Admin > Carriers**, and edit an existing carrier or add a new one for the transfer destination. In the **Dialplan Entry** field, paste the transfer dialplan, using an unused extension number (for example, `9999`): ```text theme={null} exten => 9999,1,Dial(SIP/YOUR_CARRIER_TRUNK/+1TRANSFER_PHONE_NUMBER,120,To) exten => 9999,n,Hangup() ``` Replace `9999` with any unused extension, `YOUR_CARRIER_TRUNK` with your outbound trunk name, and `+1TRANSFER_PHONE_NUMBER` with the destination number. Save. VICIdial reloads the dialplan automatically. Share the extension number with Klariqo so we configure the AI to use it. ## Test it Once Klariqo confirms your extension is registered, load a test lead using your own phone number and let the dialer call it. When you pick up, you should hear the Klariqo AI agent greet you, hold a conversation with clear audio both ways, and transfer you to your closer when you qualify. ## Security Klariqo registers with SIP digest authentication. Call audio to the Klariqo pipeline travels over an encrypted WebSocket, and recordings are stored in encrypted storage. # Add VICIdial fields to your records Source: https://docs.klariqo.com/dialer-integrations/field-enrichment Choose which of your VICIdial lead fields bind into each signed compliance record, such as a consent reference, disposition, or lead source, with honest provenance on every field. Your dialer already stores things a buyer or auditor asks about later: a consent reference, the disposition, the lead source, your own custom columns. Klariqo can bind the fields **you choose** into each signed compliance record, so the evidence travels with the call instead of living in a separate system. You pick the fields once. Every reviewed call after that carries them, inside the signature. ## What you need first Set up [Connect VICIdial](/dialer-integrations/connect-vicidial) first. Field enrichment builds on that same read-only connection, so there is nothing new to install. Klariqo reads your lead row through VICIdial's lead information API. Your API user needs the "GET LEAD INFO" permission. This is a checkbox in your VICIdial admin, not a code change. Field discovery needs recent call activity for the agents or campaign you want Klariqo to review. If the connector is brand new or idle, place or import a test call first, then run **Test connection** again. Field enrichment needs VICIdial's lead information API to return the full lead row for a recent reviewed call. After you connect VICIdial, click **Test connection** in Klariqo. If Klariqo can read the lead row, the field picker shows the available lead fields. If your VICIdial build or API user cannot provide that read, the picker cannot auto-populate fields for that connector. ## Choose your fields Klariqo reads your dialer's lead fields and lists the ones it found. These are your real columns, not a generic template. Turn on any field a buyer or auditor might ask you for later. Name it whatever you call it internally. For each field, store the **actual value**, or store only a **fingerprint** of it. A fingerprint proves the value existed and was not altered, without putting the value itself in the record. Store the value when someone needs to open or read it. Use a fingerprint when the value is sensitive and you only need to prove it was there, unchanged. Every reviewed call from then on carries your chosen fields inside the signed record. ## Consent references You can map a dialer field that contains a consent reference, such as a TrustedForm certificate URL or a Jornaya LeadiD. Klariqo records the value from your dialer and labels where it came from. Klariqo may flag when the value does not match the expected format, but Klariqo does not verify consent, confirm that the certificate or ID is valid, or decide whether the call was legally authorized. If you want a buyer to be able to open the reference themselves, store the value rather than a fingerprint. A fingerprint proves the reference was present and unchanged, but it cannot be opened. ## What the record says about each field This is the part that makes the record worth something to the person receiving it. For every field you bind, the record states: * **Where the value came from**: which dialer field it was read from, and when. * **That Klariqo captured it, and did not verify it.** The value is your dialer's. Klariqo does not check whether it is true. * **That the category is your label.** If you tag a field as a consent reference, the record records that as your classification, not as something Klariqo assigned or confirmed. * **The exact field plan** that produced the record, as a fingerprint, so a recipient can confirm which configuration was in force for that call. A field you selected that had no value on the call is recorded as not found, rather than quietly left out. Nothing you asked for goes missing without saying so. Klariqo refuses to store values that look like sensitive personal data, such as a national ID or card number, even if you map that field. The record shows the field was refused by policy rather than storing it. ## If the picker shows no fields * **Run Test connection first.** The picker fills in from that check. * **Check recent activity.** If the agents or campaign you selected have no recent reviewed calls, there is nothing for Klariqo to read yet. Place or import a call, then test again. * **Check the API user.** Without "GET LEAD INFO", Klariqo cannot read your lead row. * **Lists with no custom fields** show your standard lead columns only. The record records that it was a standard-column read, so you can tell the difference. ## What you get How each reviewed call becomes a signed, timestamped record. Exactly what a compliance record carries, and what it does not. Klariqo captures the fields you select from your dialer and signs them into the record. It does not verify that the values are true, assign the categories you choose, prove consent, or determine legal sufficiency. Records support evidence, provenance, and audit-readiness. They do not make you compliant and do not replace review by your counsel. # Dialer integrations Source: https://docs.klariqo.com/dialer-integrations/overview How Klariqo sits on top of the dialer you already run, starting with VICIdial for compliance and QA, plus optional voice AI setups for VICIdial and Twilio. Klariqo connects to the dialer you already run. It does not replace your dialer, your campaigns, or your agents. It joins as a layer on top. Most customers connect for **compliance and QA**, where Klariqo reviews your calls from their recordings and produces signed records. Klariqo can also run its **AI voice agent** on your dialer. ## Connect your dialer Review your calls for quality and compliance, with no AI on your calls. The default, lightest setup: recording access only. Run Klariqo's AI voice agent on your VICIdial as a remote SIP agent. A heavier setup, done by your VICIdial administrator. Use your own Twilio number with Klariqo's voice AI. Good for inbound and simpler setups. # Voice AI connection troubleshooting Source: https://docs.klariqo.com/dialer-integrations/troubleshooting Confirm Klariqo's voice AI is registered on your VICIdial and fix common SIP connection issues: registration failures, one-way audio, and codec mismatches. After you connect VICIdial for voice AI, Klariqo registers as a SIP peer on your system. This page helps you confirm it is working and resolve the common issues. This page is for the voice AI setup ([Connect VICIdial for voice AI](/dialer-integrations/connect-vicidial-voice)). If you connected for compliance and QA only, there is no SIP peer to register. Use the **Test connection** button in your dashboard instead. ## Confirm Klariqo is registered On your VICIdial server, run: ```text theme={null} asterisk -rx "sip show peers" | grep klariqo ``` You want to see the `klariqo-ai` peer with status `OK`. If it shows `UNKNOWN` or `UNREACHABLE`, Klariqo has not registered yet. Re-check the IP whitelist and that SIP was reloaded, then contact Klariqo. ## "Extension unavailable" or "Agent not available" Work through these in order: * **Is the Klariqo IP whitelisted?** Confirm `35.232.23.234` is allowed on both the server firewall and the cloud-provider firewall. * **Was SIP reloaded?** Run `asterisk -rx "sip reload"`. * **Is the extension registered?** Run `asterisk -rx "sip show peers"` and look for `klariqo-ai`. * **Are Klariqo's packets arriving at all?** Run `tcpdump -ni any port 5060` while Klariqo tries to connect. Zero packets means a firewall, usually the cloud layer, is dropping them upstream. This is the most decisive test when everything looks right but registration keeps failing. ## No audio or one-way audio * **Is the RTP port range open?** Open UDP ports `16384` to `32768` to the Klariqo IP. * **Is NAT configured?** Your Asterisk should have its external address set to the server's public IP. ## Wrong AI script, or transfer goes to the wrong place Contact Klariqo with your extension name or your transfer extension number, and we will check the configuration linked to it. ## Verify the transfer dialplan If you set up transfers, confirm the entry exists (replace `9999` with the extension you used): ```text theme={null} asterisk -rx "dialplan show 9999@default" ``` If nothing shows, the Carriers entry was not saved. Re-open the carrier in VICIdial Admin and confirm the Dialplan Entry field is filled in. The default context is `[default]`. If your install puts it elsewhere, swap the context name in the command. ## What to send Klariqo if you are stuck * A screenshot of your phone extension settings. * A screenshot of your remote agent settings. * The exact error or behavior you see. * The time of the test call, including your timezone. * Whether you heard ringing, the AI voice, silence, or an unavailable message. # Twilio (bring your own) Source: https://docs.klariqo.com/dialer-integrations/twilio Bring your own Twilio number to Klariqo's voice AI by pointing the number's voice webhook at a Klariqo endpoint, for inbound and simpler outbound setups. If you already use Twilio, you can run Klariqo's voice AI on your own Twilio number. You keep your Twilio account and your number, and Klariqo handles the call. This suits inbound lines and simpler setups. For VICIdial outbound at scale, the [VICIdial voice AI integration](/dialer-integrations/connect-vicidial-voice) is the primary path. ## How it works * You point your Twilio number's voice webhook at the Klariqo endpoint you are given. * Klariqo answers the call with your configured AI agent. * The call is recorded, reviewed against your scorecard, and turned into a signed compliance record, the same as any other Klariqo call. ## Set it up Twilio bring-your-own is enabled with Klariqo rather than fully self-serve, because Klariqo registers your number on its side. Contact Klariqo to turn it on. You provide your Twilio number, and Klariqo gives you the exact endpoint to set as that number's voice webhook. As with any Klariqo call, the record is evidence and provenance, not legal compliance. You remain responsible for your scripts, consent practices, retention, and counsel review. # Klariqo: the compliance layer for call centers Source: https://docs.klariqo.com/index Klariqo is the compliance layer for call centers: it turns calls on the dialer you already run into signed, independently verifiable compliance records. Klariqo turns your calls into signed, independently verifiable compliance records, on the dialer you already run. It does not replace your dialer. It records, reviews, and signs the calls that run through it, so you can prove what happened on any call. How a call becomes a signed, timestamped, verifiable compliance record, end to end. The one page to read first. ## Explore the docs Signed, independently verifiable records of every in-scope call. Review every call against your own scorecard, on AI and human-agent calls. Connect Klariqo to VICIdial, or bring your own Twilio number. Push every signed record into your own systems. Check any record's integrity yourself, in your browser. What Klariqo protects, and what stays your responsibility. Klariqo produces evidence and provenance, not legal compliance. A signed record proves what it contains and that it was not altered. It does not by itself make you compliant. You remain responsible for your scripts, consent practices, retention, and counsel review. # Data in a compliance record Source: https://docs.klariqo.com/security-privacy/data-in-a-compliance-record What data a Klariqo compliance record may contain (parties, transcript, recording hash, QA), and what the trusted timestamp authority never sees or receives. A Klariqo compliance record is a signed vCon issued for a call covered by an active scorecard. It brings the call record, analysis, fingerprint, and signature into one verifiable container. This page describes the data shape at a high level. Examples are synthetic only. ## What the record may contain The participants in the conversation. A vCon uses parties to describe who or what took part in the call. The text transcript of the conversation. A reference to the call recording. A SHA-512 content hash that fingerprints the recording. The quality and compliance review attached to the record. QA results can include statuses such as pass, needs\_review, fail, not\_applicable, or error. Sentiment analysis attached as part of the record analysis. A JWS signature using RS256, carrying Klariqo's signing certificate, so later changes are detectable. ## Synthetic record shape This example is synthetic. It is not a real call, transcript, customer record, or phone number. ```json theme={null} { "parties": [ { "role": "synthetic_caller" }, { "role": "synthetic_agent" } ], "dialog": { "transcript": "Synthetic transcript text.", "recording_reference": "synthetic-recording-reference", "content_hash": "sha512-synthetic-content-hash" }, "analysis": { "qa": { "status": "needs_review", "overall_score": 82, "compliance_status": "pass" }, "sentiment": { "label": "synthetic-sentiment" } }, "signature": { "type": "JWS", "alg": "RS256" } } ``` ## What the timestamp authority receives The trusted timestamp authority (DigiCert) receives only the record's SHA-256 fingerprint. It does not receive the transcript, audio, phone numbers, or QA content. That distinction matters. The timestamp helps show that a specific signed record existed at a point in time, without sending the call content to any outside party. See what the trusted timestamp records, and what it never receives. Check whether a signed record is valid or has been altered. ## What you control You control what is said on calls through your scripts, agent practices, and operating rules. You also control how long you retain records in your own systems and who you allow to access them. A compliance record supports evidence, provenance, and audit-readiness. It does not make you compliant, prove consent by itself, approve your scripts, or replace your retention policy and counsel review. # Security overview Source: https://docs.klariqo.com/security-privacy/overview How Klariqo protects compliance records with signing, encryption, and trusted timestamps, and what remains your responsibility around the dialer you already run. Security is shared. Klariqo protects the compliance record system and the evidence chain. You control the dialer environment, call scripts, access decisions, consent practices, and retention policy around your own operations. This page explains that split. ## What Klariqo does Klariqo signs records for calls covered by an active scorecard. The record is signed with a JWS signature using RS256, and the signature carries Klariqo's signing certificate. A signed record is tamper-evident. If the signed vCon is changed after signing, verification fails. A SHA-512 content hash fingerprints the recording inside the record. This helps tie the record to the recording content. Klariqo uses SIP digest authentication for dialer connections. Audio travels over an encrypted WebSocket. Recordings are kept in encrypted storage. Klariqo obtains an RFC 3161 trusted timestamp from DigiCert over the record's fingerprint, proving the record existed at a point in time. DigiCert does not receive the transcript, audio, phone numbers, or QA content. ## What you own You are responsible for the systems and decisions you control. | Area | Your responsibility | | ------------------- | ---------------------------------------------------------------------------------------------------------------- | | Dialer security | Secure the dialer you already run, including your own users, settings, network access, and operational controls. | | Scripts and consent | Decide what your agents say, how consent is collected, and how your scripts are reviewed. | | Access | Decide who in your organization can access records, recordings, QA results, and exports. | | Retention | Decide how long you keep records and how your retention policy is reviewed. | | Counsel review | Review your program with your own counsel before relying on any evidence workflow. | ## Shared responsibility in practice Signed records, content hashes, QA results, trusted timestamps, and verification. Scripts, consent, dialer administration, access control, retention, and legal review. ## What security does not mean Security controls help protect the record and its provenance. They do not decide whether a call was legally placed, whether a script is approved, or whether your retention policy is correct. Klariqo provides evidence, provenance, and audit-readiness. Klariqo does not make you compliant, prove consent by itself, win a lawsuit, or replace your scripts, retention policy, access decisions, dialer security, or counsel review. # Public verifier privacy Source: https://docs.klariqo.com/security-privacy/public-verifier-privacy The Klariqo public verifier runs entirely in your browser: records, keys, and hashes you check never leave your machine and nothing is uploaded to Klariqo. The public verifier at [klariqo.com/vcon](https://klariqo.com/vcon/) checks a compliance record's signature. It is built to be private: the check runs entirely in your browser. ## What this means * When you paste or upload a record, it is verified locally in your browser. The record is not sent to Klariqo or to any server. * The verifier works on any vCon, not only Klariqo's, and you do not need a Klariqo account to use it. * Because the check is local, you can verify a record that contains sensitive call content without exposing that content to anyone. ## Why it is built this way Verification is only trustworthy if you do not have to trust the verifier. Running it in your browser means you can confirm a record's integrity yourself, independently, without handing the record to a third party. Check a record's integrity, step by step. What the signature proves. # Glossary Source: https://docs.klariqo.com/start-here/glossary Key Klariqo terms defined in one place: vCon, compliance record, content hash, JWS signature, verifier, trusted timestamp, scorecard, QA result, and more. ## vCon A vCon is an IETF-track conversation-record format for parties, dialog, and analysis. Klariqo issues signed vCons as compliance records, but Klariqo does not own the vCon standard. ## Compliance record / evidence record A compliance record, also called an evidence record, is a signed vCon Klariqo issues for a call covered by an active scorecard. It carries the call record, analysis, and signature together. ## Content hash A content hash is a SHA-512 fingerprint of the recording. It helps tie the record to the recording content. ## JWS signature A JWS signature is the signature Klariqo applies to a vCon using RS256. It carries Klariqo's signing certificate and makes later changes detectable. ## Self-asserted Self-asserted means Klariqo publishes its own signing key. Klariqo is not a certificate authority, so the signature proves the record was signed by Klariqo's key and was not altered after signing. ## Public verifier The public verifier is the in-browser tool at `klariqo.com/vcon` that checks a vCon. It reports whether the signature is valid, whether the record was altered, and whether it was signed by Klariqo's published key. ## Trusted timestamp A trusted timestamp is an RFC 3161 timestamp token that Klariqo obtains from DigiCert, a global certificate authority Klariqo does not control. It stamps the record's fingerprint with the time, so anyone can independently confirm the record existed at that moment and was not backdated. DigiCert receives only the fingerprint, never the transcript, audio, phone numbers, or QA content. ## Scorecard A scorecard is the customer-configured operating rule set used to review calls. It contains required elements and prohibited claims, each with critical and enabled flags. ## QA result A QA result is the review outcome for a call, with status values of `pass`, `needs_review`, `fail`, `not_applicable`, or `error`. It also includes `overall_score` when scored and `compliance_status` as `pass`, `fail`, or `not_evaluated`. ## Standard Webhooks Standard Webhooks is the signing scheme Klariqo uses for compliance export deliveries. Each delivery includes `webhook-id`, `webhook-timestamp`, and `webhook-signature`, with signed content built from `id.timestamp.body`. ## VICIdial VICIdial is the existing dialer Klariqo can connect to as a remote SIP agent. Klariqo sits on top of the dialer you already run; it does not replace it. ## Honesty boundary These terms describe evidence, provenance, and audit-readiness. They do not mean Klariqo makes you compliant, proves consent by itself, wins a lawsuit, or replaces your scripts, retention policy, or counsel review. # How Klariqo works Source: https://docs.klariqo.com/start-here/how-klariqo-works How Klariqo sits on top of your existing dialer to review calls for quality and compliance and turn each call into a signed, independently verifiable record. Klariqo is a layer on top of your existing dialer. It does not replace your dialer, your campaigns, or your agents. It handles or reviews the calls that run through your system, checks them against your rules, and produces a signed record of each one. ## The flow ```mermaid theme={null} flowchart LR A[Your dialer] --> B[Klariqo: AI calls and call QA] B --> C[Signed compliance record] C --> D[Public verifier] C --> E[Export webhook to your systems] ``` ## What happens on a call * For a Klariqo AI call, the voice agent handles the conversation and can transfer a qualified lead to your human closer. * For any in-scope call, AI or human-agent, Klariqo reviews it against your scorecard and produces a compliance record, which is a signed vCon. * The record carries the transcript, a recording reference, the QA result, and sentiment, all signed so that tampering is detectable. * You can verify any record yourself, and you can have records pushed into your own systems by webhook. ## Where to go next A call from audio to verified record, end to end. How calls are reviewed against your rules. Connect Klariqo to your dialer. Receive every record in your own systems. Klariqo produces evidence and provenance, not legal compliance. A signed record proves what it contains and that it was not altered. It does not by itself make you compliant. See [trust and honesty boundaries](/start-here/trust-and-honesty). # Trust and honesty boundaries Source: https://docs.klariqo.com/start-here/trust-and-honesty What Klariqo proves, what it does not, and where your responsibility sits: evidence and provenance of a call, not legal compliance, consent, or approval. Klariqo produces strong evidence about your calls. It is deliberate about not overstating what that evidence means, because overstating it is exactly what makes a compliance story fall apart under scrutiny. ## What Klariqo can prove * A record's contents, the transcript, a recording reference, the QA result, and sentiment, exactly as they were signed. * That a record was not altered since it was signed. * That a record was signed by Klariqo's published key (self-asserted). * That an independent authority (DigiCert) timestamped a record's fingerprint at a point in time. ## What Klariqo does not do * It does not make you compliant. Compliance depends on your scripts, your disclosures, your consent practices, and the law that applies to you. * It does not, by itself, prove a call was lawful or that consent was valid. * It is not legal advice. * Scorecard presets are starter examples for your own review, not legal templates. ## Shared responsibility Klariqo gives you tamper-evident, verifiable evidence of what happened on your calls. The compliance program around that evidence is yours: your scripts, your consent and disclosures, your retention policy, and review by your own counsel. What a record can and cannot prove. Check any record's integrity yourself.