Technical overview
Meaning, not records. MTN FieldMap is a map of what your data means, built from structure, maintained outside your data path, and honest about what it does not know.
Where Guide sits
Above the data path, not inside it. Your records never route through MTN.
How a question is answered
A language model appears at exactly two points. Everything between them is deterministic.
A question becomes one or more goals from a closed, enumerated catalog. Selection from a fixed set, never free-form query generation.
Terms resolve to identities in the FieldMap: resolved, ambiguous-with-candidates, or unknown. Never a silent best guess.
Before anything executes, the engine decides whether the map can support the question, and names what is missing if it cannot.
A fixed plan per goal type produces a structured answer and the assertions it was computed from.
The model renders the structured answer into prose. It adds nothing, including nothing about gaps it was not shown.
Goal, answer, and narration are logged together, so any answer can be replayed and disputed mechanically.
What Guide reads
Guide builds MTN FieldMap from descriptions of your systems rather than from their contents. Schema-level evidence is enough to begin, which is what lets an engagement start before a data agreement is in place.
Structural
DDL, JSON Schema, OpenAPI specs, data dictionaries, and warehouse catalogs
Prose
Documentation, integration guides, and vendor references
Examples
Synthetic or anonymized payloads, where values clarify meaning
Human answers
Answers to specific questions, recorded as evidence in their own right
Each modality keeps an evidence shape faithful to the artifact it came from.
MTN FieldMap
Concepts and the relationships between them, assembled from assertions. Every one records what it rests on.
Layers and change containment
Each source is a layer, and layers compose recursively.
Uncertainty and human review
An answer is only as good as the weakest assertion underneath it.
- patient_id maps across all five systems0.98
- production = sum(billed_amount)certain
- “adjustment” as defined in Practice C0.41 ◄
- location_id mapped from site_code, Practice E0.62
The answer inherits 0.41, the weakest assertion it rests on, not the average of the four.
That one assertion becomes the review queue: what does “adjustment” mean in Practice C? Answer it, and the whole conclusion moves.
Calibrated confidence and guided review
Trust levels are validated against outcomes rather than asserted by the model that produced them, and guided elicitation ranks which questions are worth a person’s attention. Where the evidence does not support a score, the engine declines to invent one.
Security and regulatory posture
The strongest control is architectural: the sensitive data mostly isn’t there.
Schema-first by default
Schemas, documentation, and synthetic examples are enough to begin, with no PHI and no production access. That materially shortens security review, and it is a design property rather than a configuration option.
When deeper access is warranted
Some work needs more than schemas: value-level disambiguation, or drift detection against live data. That is a separate, explicit step taken under a BAA, scoped to the specific need, and never a precondition for getting started.
Audit and traceability
Traceability is how the map is built, not a logging layer added around it.
Model independence
Guide is not tied to one model vendor. Providers are configured per deployment, so model choice follows your procurement and data agreements rather than dictating them.
Integration surface
If you are an engineer or SI technical lead, here is what you get to build against.
Map export
The evidence and attribution behind every assertion
Mappings and specs
Yours to implement in your own pipeline
Sandbox
Pre-engagement schema introspection
Ready to discuss architecture?
We'll walk through how this fits your stack, what a bounded evaluation looks like, and where the boundaries of the system actually are.