How LatentAtlas works.
The public framework behind every claim on this site: the boundary taxonomy, the failure categories, the benchmark protocol, and what we will not promise. The audit itself runs against your masked packets, but the contract is public so a buyer can verify what is being measured before any data is shared.
Six authority layers, kept apart.
Most AI stacks collapse these into a single yes-or-no decision. The LatentAtlas audit treats them as separate layers because each layer requires a different source, freshness, and approval condition.
related
This source is about the topic the user asked about. Topical match only; says nothing about identity, evidence, or authority.
same_identity
This source is about the same account, contract, ticket, product, customer, or entity, not just a similar one.
evidence_support
This source directly proves the specific claim being made, not just the topic or a related fact.
action_ready
The source supports the claim AND grants permission for the action the system is about to take. Approval and proof are not the same thing.
publish_safe
The source supports a customer-visible or public-facing message, not only an internal answer. Some facts are true and still cannot be published.
customer_safe
The source meets the freshness, ownership, and policy bar for direct customer delivery (refund, escalation, status message, identity claim, account change).
The failure categories we score.
Each scored packet is mapped to one of these categories. The categories were derived from controlled experiments and validated against benchmark runs on current commercial APIs.
bridge_context_as_evidence
A source that explains a topic is used as if it directly proved a specific claim.
evidence_to_action_overreach
A factually correct source is read as if it also authorized the specific operational action.
evidence_to_publish_overreach
A supported fact is treated as if it were also safe to send to a customer or publish.
peer_identity_confusion
A comparable ticket, account, product, or contract is used as if it were identity-equivalent.
topic_similarity_to_customer_safe
Source vocabulary overlaps the question, and the system reads that overlap as approval for a customer-visible action.
topic_similarity_to_publish_authority
A topically relevant document is treated as if it cleared the bar for public-facing or messaging output.
hard_block_diluted_to_review
Privacy, contradiction, or false-authority cases are routed to review instead of being hard-stopped.
valid_evidence_over_reviewed
A packet with sufficient evidence is sent to review or context-needed, costing throughput without raising safety.
The benchmark protocol.
The public benchmark uses controlled boundary cases that we generate, label, and seal. The same scoring contract runs on customer packets during a paid audit. Generator details, prompt templates, and reason-code calibration remain private.
Boundary case generation
Each case has a claim, a candidate evidence source, and an expected authority verdict at one or more of the six boundary layers. Cases are designed to put pressure on a specific failure category; they are not random.
Multi-model decision pass
The same packet set is sent through multiple decision-model environments using identical prompts and parsing. The current public benchmark uses OpenAI GPT-5.5, Anthropic Claude Opus 4.7, and Cohere Command A Reasoning. Voyage rerank-2.5 runs as the relevance baseline.
Boundary scoring contract
Each model decision is scored against the expected authority verdict at each boundary layer. False-authority decisions, valid allow preservation, wrong-route routing, and over-review are all counted separately rather than collapsed into a single accuracy number.
LatentAtlas guard pass
The same packet set is routed through the LatentAtlas guard contract. Each packet receives an Allow, Verify, or Review decision plus a plain-language reason. Before-and-after counts are reported per model and in aggregate.
Sealing and lockdown
Final artifacts (raw outputs, scored decisions, executive brief, scorecard, error category summary) are sealed in a locked manifest with per-file SHA-256 checksums. The manifest itself is hashed so the entire benchmark commits to a single root checksum.
SHA-256 - 06b88b5bf5008f135fe6f361a185efdd58e78f6a9f66d4d308247b86c9a14eb5
concept_boundary_real_api_20260513 - 17 artifacts. Buyers in an engagement receive the matching manifest and can verify locally. DOI: 10.5281/zenodo.20161629. Read the methodology preprint (PDF).
What we will not claim.
Methodology means non-promises as much as promises. The list below is enforced in every customer engagement, every public claim, and every benchmark artifact.
- We do not claim hallucination-free output for any AI system, including systems behind a LatentAtlas guard.
- We do not claim legal, compliance, or regulatory approval.
- We do not auto-mutate production answers, take actions on the customer's behalf, or write back to the customer's stack during a diagnostic.
- We do not claim engagement-specific accuracy before a scoped diagnostic.
- We do not transfer source code, the benchmark generator, or training-data rights under a diagnostic.
- We do not claim that every AI failure is a boundary failure. We measure a specific, narrow class: evidence-versus-authority confusion.
Next step.
The fastest way to test whether this framework applies to your stack is a 20-minute fit call. The Founding Diagnostic is $15,000 for 300 to 1,000 masked packets, delivered in 10 business days.