Enrichment adds potentially useful information about an identifier; it does not prove who is currently speaking or whether every returned field is current. Treat person, company, carrier, and line-type data as nullable, correctable context. Keep the conversation useful when it is absent, use neutral language until identity is established, and never disclose sensitive details merely because a lookup returned them.
What question does enrichment answer?
Caller enrichment answers: “What external context is available for this phone number?”
It does not automatically answer:
- Who is holding the phone right now?
- Did the person consent to disclosure of every returned attribute?
- Is a company association still current?
- Does the number uniquely identify one human across time?
- Is the external source more authoritative than a direct correction from the caller?
Those are identity, privacy, freshness, and authority questions. A lookup result can inform them, but it cannot silently settle them.
What enrichment does Northsun (formerly Mnemix) return?
POST /v1/recall_and_enrich can return three nullable branches:
{
"enrichment": {
"person": { "name": "...", "title": "...", "company": "..." },
"company": { "name": "...", "address": {} },
"phone": { "carrier": "...", "line_type": "..." }
}
}
The public enrichment vendors are Trestle and Twilio Lookup. Individual branches may be null, and fields inside an available branch may also be null or absent. A correct integration treats that variability as part of the contract.
How is enrichment different from memory?
Enrichment and memory have different evidence origins:
- Enrichment is external context associated with an identifier.
- Memory is what the tenant has observed in prior interactions.
A first-time caller may have enrichment and no prior memory. A returning caller may have useful interaction history while live enrichment is unavailable or unnecessary. Returning both in one response does not make them equally authoritative.
Preserve the distinction in your application. A tenant-observed preference, a caller-confirmed correction, and an externally enriched company field should not collapse into one unlabeled sentence.
What is a safe opening?
Prefer language that leaves room for correction.
Risky:
“Hello, Mike Reynolds from Northwind Logistics. Your fleet account has an overdue balance.”
Safer:
“Thanks for calling. I may have prior context associated with this number—who am I speaking with today?”
After the caller establishes identity and the application's own disclosure policy allows it, the agent can use relevant context more specifically. The precise script depends on the interaction, sensitivity, and platform requirements; enrichment alone should not unlock disclosure.
What should happen when enrichment is null?
Continue the conversation. Missing enrichment is not an exceptional identity state and should not become a greeting blocker.
Use fallbacks that depend only on information the caller supplies or on tenant memory that your application is permitted to reveal. Avoid statements such as “we could not verify you” unless an actual verification process ran and failed. A null enrichment branch means no value was returned for that branch; it does not explain why and does not prove anything about the caller.
How should corrections work?
Let the caller correct names, affiliations, and phone classifications. Preserve the correction's provenance rather than quietly overwriting every historical record.
For example:
- enriched context says a person works at Company A;
- the caller says they moved to Company B last month;
- the system records the direct correction with its effective time and source;
- future serving policy can prefer the stronger, newer evidence while retaining history.
Northsun's repository describes evidence and bi-temporal primitives for this class of governance. Those primitives are substrate and design context, not a claim that the frozen caller API exposes a public facts or evidence-management endpoint.
How do privacy and enrichment interact?
Availability is not permission. Before putting an enriched attribute into a prompt or response, consider:
- whether the application needs it for the current purpose;
- whether the current user is allowed to receive it;
- whether speaking it aloud could expose information to another person;
- whether the value is sensitive or easy to misuse;
- how the user can correct or contest it;
- how retention and deletion apply to the derived context.
Do not describe these design practices as a compliance certification. Platform, recording, consent, and data-handling obligations remain the integrator's responsibility.
How should you test an enrichment integration?
Use at least four controlled cases:
- a returning caller with memory and cached enrichment;
- a first-time caller with partial enrichment;
- a caller with every enrichment branch null;
- a returned value the test caller explicitly corrects.
For each case, verify that the agent remains useful, avoids identity claims, does not reveal unnecessary attributes, and preserves the correction path. Also test degraded recall independently; a safe enrichment fallback should not hide authentication or service errors.
What can you claim publicly?
Northsun is the memory and enrichment layer for AI agents. Public documentation may name Trestle and Twilio Lookup and describe the nullable response branches. It must not turn those facts into fabricated identity-resolution, customer, benchmark, compliance, or integration claims.
The exact caller API remains the three-route surface in the API reference. Broader governed-fact and provenance concepts do not create additional public REST endpoints.
Build the responsible path
Read Caller enrichment for the response contract, then follow What is caller memory? and the Quickstart to test partial enrichment, neutral fallback, write-back, and later recall as one controlled lifecycle.