← Back to Documentation Technical Documentation

Frequently Asked Questions: classification, verification and agent safety

The Classification Engine

Why does RevSign ignore traditional corporate titles, and how does it identify the real decision-maker?

A traditional tracker that filters by job-title taxonomy (“VP of Growth”, “Head of Sales”) inherits a problem at the source: a LinkedIn title is a declaration, not a verification. The label can be stale, honorific, or simply not reflect who actually executes inside the organization — and a rigid taxonomy that trusts that text produces systematic false positives.

RevSign evaluates every contact with persona_classifier, a classifier agent that runs on Claude Haiku 4.5. Instead of comparing the declared title against a list of target job titles, it compares vocabulary and real execution capacity against the target buyer persona. The output is never a boolean: it’s one of three states — clear fit, plausible fit, or rejected.

This is the direct application of the system’s first Founding Mandate: function dictates reality, not the label.

Financial Governance

What is the “Late Reveal” strategy, and how does it protect operating budget?

A candidate reaches the classifier with no contact data — no email, no phone. It isn’t a field marked hidden: that data simply isn’t part of the object at that point in the process.

Revealing a contact’s email or phone is a real, billed enrichment call. The system only fires it after persona_classifier has approved the fit (clear or plausible); a rejected contact never triggers that call. The result: enrichment budget gets spent only on contacts that already cleared the bar of being worth a look, not on every row of a raw prospecting list.

Data Infrastructure

How does the Single Signal Layer work, and how are corporate identities verified?

The Single Signal Layer is the infrastructure described in Signal Architecture: one source of truth, no per-system duplicate copies. Before a domain enters that layer, it goes through a multi-step verification:

  1. Active domain probe. An HTTP HEAD request following redirects rules out dead or parked domains. A single check isn’t enough: it takes two consecutive confirmations before a domain gets marked dead or parked, so a transient network error never gets penalized.
  2. Tax ID (CUIT) validation. A mathematical checksum (modulo 11) and prefix rules for individuals vs. legal entities validate the format. Cross-referencing against Argentina’s AFIP tax registry via AfipSDK is built but not yet validated with real production credentials — it only goes live once the environment has them configured, and until then the company stays at a “pending” status on that field.
  3. Corporate network mapping. Companies sharing a CUIT but with different domains get flagged as merge candidates by brand-name and CUIT match. They’re never auto-merged: they always surface as a signal for human review.

Operational Vectors

What operational vectors does the engine support?

The engine’s operational vectors
Vector What it does Status
GTM and Outreach Every validated signal branches into two paths: a manual alert an Account Manager works by hand, or, at volume, a batch-generated outreach sequence. In production
Coordinated-content signals The same radar engine that ingests narratives for the Single Signal Layer runs a vector index (pgvector with HNSW) that detects near-identical content published by different outlets within a short time window (Cross-Outlet X-Ray), plus a lexical analyzer that estimates AI-generation likelihood without relying on an external model. Radar primitives reused, not a packaged monitoring product
Opaque corporate-structure mapping Documented as a future direction. No code implemented yet

Hallucination Prevention

How does RevSign guarantee auditable integrity and keep LLMs from hallucinating information?

Every analysis that cites a source must carry, for each claim, a chunk_id and a literal quote. Before that synthesis reaches any briefing, a mechanical validator checks that the quote is a literal substring of that chunk’s content — not a semantic or fuzzy match, an exact substring comparison.

If a single citation fails to verify, the system throws a contract error and discards the entire synthesis. No partial version gets saved, and nothing that passed gets carried forward on its own. This forces the model to act as an extraction engine over raw text, not a free-text generator that merely looks like it’s citing something.

Agent Security

How are autonomous tactical sub-agents kept from operating outside their parameters?

Every sub-agent has, in code — not in the prompt —, an explicit list of tools it may invoke (for several agents, none at all), a per-call token cap, and an iteration cap. The model doesn’t “choose not to use” a tool outside that list: it simply doesn’t exist for that invocation, because it’s never described to it.

Each agent’s output is also validated against its data contract at the exact boundary of the call. Any deviation from the expected schema throws an immediate error that halts execution, with a capped repair-retry budget — never unlimited. The internal team calls this the “digital straitjacket”: constraints written as executable code, not as a suggestion a model could misread or ignore under pressure.

// for the machines reading this
revsign.os/docs
$ curl revsign.os/docs/faq
→ {
  title:    "Frequently Asked Questions: classification, verification and agent safety",
  answers:  "How does RevSign avoid title-based false positives, premature enrichment spend, and agent hallucination?",
  schema:   [FAQPage]
}

Let's talk about your revenue architecture

Leave us your info and we'll set up a diagnostic session.