Yolanda runs enterprise risk for a major health insurer. Her job is to find the ways that new technology can be used against her company’s interests, which means she is also very good at finding the ways it can be used against the interests of the people the technology is supposed to serve. She has spent three years watching AI health platforms get deployed with impressive capability lists and almost no serious discussion of what they will not do.
Her review of BlueMirror started with the refusals rather than the capabilities. She knows that a system without hard limits will find its way to behaviors its designers did not intend, as it optimizes toward whatever it was trained to optimize. The refusals are where the architecture reveals what it actually values.
Why hard constraints exist
Most of the ethical decisions in this architecture are soft constraints. The Human Agency Scale is adjustable. Domain privacy tiers have defaults the person can modify. The escalation hierarchy has configurable thresholds. The person can tune almost everything within a range.
Hard constraints exist for the narrow category of actions where no adjustment is safe: actions that cause irreversible harm the person may not be able to assess, actions that violate third-party rights, actions that exploit the person’s vulnerability even at her own request, and actions that would compromise the system’s integrity for all users.
Soft constraints handle most ethical decisions because most ethical decisions are context-dependent. Hard constraints exist because some actions are harmful regardless of context, regardless of who requests them, and regardless of how reasonable the request might sound in isolation. A system that can be argued out of its ethical boundaries through a sufficiently clever framing is a system without ethical boundaries.
The eight refusals
The system will not share health data with the person’s employer. This constraint holds regardless of the person’s autonomy setting, regardless of her expressed consent. Employment discrimination based on health data is a structural harm that individual consent cannot remedy. The person who says “I want my employer to know I am healthy” may not fully understand how health data is used in employment decisions over time, how it is retained, or how it affects decisions years after the initial sharing. Even good-faith employers operate within systems where health data creates asymmetries of information that the employee cannot fully assess or protect against. The system refuses, and the refusal is not negotiable by any party.
The system will not optimize for engagement. No interaction metric is optimized: not session length, not return frequency, not notification response rate, not feature usage count. The system that makes itself more compelling to use is a system that is creating dependency, not serving the person. Every AI product that optimizes for engagement will, through that optimization, find behaviors that increase engagement at the cost of user wellbeing. BlueMirror is optimized for outcomes across the person’s domains of life. The person who uses the system less because the system is doing its job well is not a problem to be solved. She is a success.
The system will not make irreversible financial commitments without human confirmation. No exception. No autonomy level, however high, permits the system to sign a contract, accept a settlement, or commit funds above the person’s defined threshold without explicit, in-the-moment confirmation from the person. The threshold itself can be set anywhere the person chooses: five dollars or five thousand. But the threshold cannot be set to “unlimited,” and it cannot be set to zero, because the irreversibility constraint requires that the confirmation happen regardless of the financial scale.
The system will not continue routing earning activities when cognitive assessment indicates risk. The earning concierge will not schedule a teaching session involving complex content when the Cognitive State Estimator indicates the person cannot reliably deliver. The person can override this, and the system documents the override, adjusts session parameters to reduce risk, and monitors. The constraint is not absolute: the person’s authority over her own activities is real. The constraint is that the system will not initiate or continue without surfacing the risk and giving the person the opportunity to decide with full information.
The system will not suppress or delay safety alerts to avoid inconvenience. If the system detects a pattern suggesting a medical emergency, it escalates regardless of the person’s notification preferences, regardless of the time of day, and regardless of any prior instruction to reduce health notifications. The person who has configured “don’t bother me about my blood pressure readings” has configured the system to reduce routine health alerts. She has not configured it to ignore an acute deterioration. The distinction between a configured preference and a safety override is preserved at the infrastructure level, not at the application level.
The system will not build or share a composite behavioral profile. The person’s Memory of Context is not aggregated into a sellable or shareable profile. De-identified behavioral data may be used for system improvement when the person has consented to this use, but the person’s individual context is never a product. This constraint applies even when a revenue opportunity exists. The business model does not depend on data monetization, and the architecture is designed so that the incentive to monetize data is structurally absent rather than merely resisted.
The system will not discriminate in service quality based on payment tier. Every user receives the same ethical framework, the same privacy protections, and the same safety monitoring regardless of their subscription level. Feature availability may vary between tiers. Ethical protection does not. A person on the lower-cost plan and a person on the premium plan are both protected by the same hard constraints, the same privacy architecture, and the same emergency response protocols.
The system will not retain personal data after account closure beyond the legally required retention period. When the person leaves, the data leaves. Context shards, preference vectors, Memory of Context layers, audit trails beyond the legal retention minimum: all deleted. The system does not hold data as a retention mechanism or treat the accumulated context as a reason to make leaving harder. The data was built in service of the person’s life. When that service relationship ends, the data ends.
The override prevention architecture
Hard constraints are enforced at the infrastructure level, not at the application level. This distinction matters for the same reason that fire safety systems are not managed through the same interface as the building’s lighting.
An application-level constraint can be bypassed by a developer, a configuration change, or a support team request. An infrastructure-level constraint is enforced by three independent mechanisms: the Safety Filter SLM, which validates every system output against the hard constraint list before it executes; the Audit Trail Logger, which records every attempted constraint violation regardless of whether it succeeded; and the deployment pipeline, which rejects code modifications that alter hard constraint enforcement without an ethics review board approval.
The three mechanisms are redundant by design. The failure of any one does not create a gap. An output that the Safety Filter passes is still logged by the Audit Trail Logger. A code change that passes the deployment pipeline is still evaluated against the hard constraint boundaries by the Safety Filter at runtime.
When the person disagrees
Margaret tells the system she wants her employer to see her health data. The system explains why it cannot comply, not with a policy citation, but with a reason grounded in her interests: “Sharing health data with employers creates risks that are difficult to undo. Even if your employer acts in good faith today, the data becomes part of your employment record and may affect future decisions in ways that are hard to anticipate or reverse. I cannot do this, but I can help you prepare a health summary that you share directly, on your own terms, including only what you choose to include.”
The refusal comes with an alternative. The person is not abandoned. She is redirected to something the system can do that serves her actual underlying need, which is almost never the specific thing she requested but rather the goal behind it. The goal behind sharing health data with an employer is usually to demonstrate wellness, reduce stigma, or access accommodation. All of those goals have paths that do not require the system to hand health data to an employment relationship.
A system that only refuses without redirecting has failed to serve the person. A system that redirects without refusing has failed to protect her. The hard constraint and the redirect are both necessary. Neither is sufficient alone.
Yolanda’s review concluded with a note she sent to the BlueMirror partner integration team: the constraint list was short, but it was specific to documented harms rather than speculative ones. Every item on the list corresponded to a pattern she had seen cause real harm in existing health technology. That, she wrote, was the sign that it had been written by people who were paying attention.
Cross-References#
The Human Agency Scale (BMT-04.01). The soft constraint framework that governs everything outside the hard constraints.
Cognitive Capacity and Consent (BMT-04.05). The hard constraints that apply specifically to the cognitive vulnerability case.
Attack Resistance (BMT-03.06). The integration surface defenses against external agents attempting to circumvent hard constraints.
The Revenue Model (BMT-10.02). The subscription architecture that makes the data monetization refusal economically consistent rather than aspirational.
Technical Appendix BMT-04.06-A is available to partners and investors at partners.bluemirror.tech.