The boundary activates before a protected generative call whenever the endpoint's deployment class requires pseudonymization. The selected profile determines which entity types and numerical facts may cross that boundary.
Confidentiality Boundary
Keep obvious confidential identifiers out of protected model calls — and restore them after validation.
Applies deployment-aware pseudonymization before generative inference, preserves relationships with typed aliases, and restores values only after integrity and leak checks.
A provider receives typed aliases instead of recognized protected values, reasons over stable relationships, and returns a response that is restored only inside the originating scope after leak and alias-integrity checks succeed.
Why it exists
The problem this module is designed to solve.
Teams often face a false choice: send obvious identities and confidential values to a public model, or forbid useful external inference entirely. Simple redaction is not enough because it can destroy the relationships, quantities and references the model needs to reason correctly.
02 / How it works
A bounded path from need to accountable result.
The public model below describes responsibilities and decisions, not sensitive implementation details, provider secrets or customer data.
- 01
Select the exposure profile
Use the endpoint's declared public, controlled-private or trusted-local class to choose a bounded protection policy before dispatch.
- 02
Recognize and alias
Replace detected names, contacts, credentials, identifiers, accounts and configured terms with stable typed aliases isolated to the active scope.
- 03
Preserve useful reasoning
Keep relationships between aliases and, where policy permits, retain dates, amounts or standalone figures needed for comparison and calculation.
- 04
Validate and restore
Reject raw-value leakage or unknown aliases, then reconstruct only known values from the current tenant, user and conversation scope.
03 / Customer and operator value
Reduces avoidable disclosure of company names, people, contacts, credentials, accounts, identifiers and configured terms while preserving symbolic reasoning and exact reconstruction inside the active scope.
Public and private policy profiles
Scope-isolated reversible aliases
Reasoning-preserving entity relationships
Fail-closed output and opaque-media controls
04 / Where it creates value
Concrete situations, not generic feature claims.
These are representative product situations. Every deployment still requires its own policy, data boundary and acceptance criteria.
Client work with a public LLM
Reason over a dossier while keeping recognized company, person, contact and account identifiers outside the provider request.
Controlled private inference
Apply a less destructive profile for a contractually controlled endpoint while preserving a visible, testable boundary.
Mixed-provider architecture
Let local, private and public endpoints coexist without treating one protocol or automatic fallback as a privacy guarantee.
05 / Role in the cognitive system
A clear responsibility creates a trustworthy boundary.
No module is allowed to become an invisible monolith. It owns a narrow contract, composes with named capabilities and refuses responsibilities that belong elsewhere.
What it owns
- Pre-egress text pseudonymization
- Scoped alias vault
- Response integrity and restoration
- Safe aggregate confidentiality trace
What it composes with
Cognitive EngineInference GatewayPolicyObservability
What it refuses to own
Boundary before convenience.
It is pseudonymization, not anonymization or encryption. Unlabelled names can be missed; strict mode masks dates and amounts; raw remote media and untrusted external embeddings are rejected rather than falsely presented as protected.
06 / Vision and mission
Sovereignty without isolation
The boundary supports Mentaview's vision of useful AI across provider boundaries: teams can retain architectural choice without pretending that public and private execution expose data in the same way.
AI systems that remain useful, inspectable and sovereign across models, providers and deployment boundaries.
Build the cognitive layer that chooses the smallest sufficient path and turns evidence into accountable action.
Capture the value of advanced AI without surrendering data control, architectural freedom or intellectual honesty.
07 / Evidence and maturity
What the current label means — and what remains open.
ENGINEERING MATURITYM4Mentaview internal laboratory assessment
OBJECTIVE REVIEW
Passed with moderate confidence
The fail-closed provider boundary, reproducible Unicode-derived profile and durable local decision evidence are implemented and tested; representative multilingual calibration is absent.
OPEN LIMITS
- No customer-approved representative multilingual calibration corpus.
- Thresholds have not been approved by customer privacy owners.
- No legal review or independent operating-effectiveness evidence.
What exists today
The reversible engine, mandatory provider wrapper, deployment-profile selection, startup gates, aggregate trace, metrics and adversarial leak tests are implemented.
Implemented
A software or contract boundary exists in the current development project. This does not by itself mean general availability or independent certification.
What must earn promotion
Measure multilingual effectiveness on approved representative customer data, calibrate detection thresholds with privacy owners and obtain independent operating-effectiveness evidence.
Public truth boundary: M4− is a non-standard Mentaview engineering label for internal laboratory validation. It is not an official TRL decision and does not assert production qualification, customer acceptance, independent assurance, certification or universal performance. Inspect the complete assessment record.