Grounded Intelligences

Tag: responsible-ai

Ethical AI, fairness frameworks, explainability, and behavioral guardrails for AI systems.

  • The AI Roles Worth Targeting in 2026: A Field Guide for Unconventional Candidates

    I spent 19 years in defense finance and digital transformation before becoming someone companies want for AI work, and here is what I see in 2026: the most interesting AI roles are not being filled by candidates submitting the standard machine learning pipeline resume. They are being filled by people who understand both the technology and the domain it’s being applied in. The pure-ML resume is now common enough to be a commodity. The combination is rare enough to be a differentiator.

    Where Domain Expertise Beats Pure ML Background

    Several roles reward domain depth over model depth. The AI Solutions Architect needs system design thinking and domain credibility — the job is fitting AI into a real organization with real constraints, and knowledge of model internals alone doesn’t get you there. The AI Product Manager needs to understand user behavior and organizational dynamics; candidates from a pure ML background often struggle here precisely because the hard part isn’t the model. The AI Ethicist or Responsible AI Lead draws on philosophy, law, social science, and clinical backgrounds — none of which appear on a standard ML résumé. And the ML Evaluator or RLHF Specialist needs cognitive science, linguistics, and domain expertise far more than systems engineering. In each case the rare skill is the human and organizational understanding, not the technical baseline.

    A Case Study in Recombination

    My own path is the argument. A Licensed Marriage and Family Therapist license, a master’s in Industrial/Organizational Psychology, 19 years in defense finance at Lockheed Martin, and a track record building AI systems that produced quantified outcomes — $360K in annual cost avoidance on a major defense aircraft program Withholds automation, 415,000 tax scenarios processed in 4 hours through the internal tax scenario classifier. None of those pieces gets you the job on its own. A therapist isn’t an AI engineer; an I/O psychologist isn’t a finance lead; a defense finance background isn’t responsible-AI expertise. Together, though, they represent something genuinely uncommon: a person who can build the system and understand the human, organizational, and regulatory context it has to live inside.

    What Companies Want but Can’t Articulate

    What organizations are actually hiring for — even when they can’t put it in a job description — is someone who will catch the problems that emerge at the intersection of the model and the organization. The model that is technically correct but organizationally wrong. The system that is accurate but not trusted by the people meant to use it. The tool that performs beautifully in evaluation and fails in deployment because nobody accounted for how humans actually behave around it. Those failures don’t show up in a model card. They show up six months after launch, and the person who can foresee them is worth more than the person who can squeeze another point of accuracy out of a training run.

    How to Position as an Unconventional Candidate

    The move that works is building in public. Every project you document is evidence — not a claim about what you could do, but a record of what you did. This site is the argument: posts about building real systems, quantified outcomes, and the behavioral science lens most AI engineers don’t carry. A working job search dashboard at jobs.groundedintelligences.com tells a story no resume bullet can, because it’s a live system someone can actually use and inspect. When the standard candidate hands over a list of skills, the unconventional candidate hands over a working thing and says: I built that, here’s what it does, here’s what it cost, here’s what it produced.

    The Most Important Credential in 2026

    The credential that matters most now is a portfolio of working AI systems with documented outcomes. Not a certification, not a bootcamp completion, not a GitHub repository full of Jupyter notebooks that ran once on a laptop — working systems with real usage and quantified results. The bar has risen because building has gotten easier, which means the proof of competence is no longer knowing how but having done. A deployed system with users and numbers settles the question that a credential only gestures at. I wrote about the discipline behind shipping those systems in lessons from 17 enterprise projects.

    What Transfers

    These positioning principles apply in any field where the standard path is well-worn and the non-standard path creates genuine differentiation. When everyone arrives with the same resume, the credential stops distinguishing anyone — and the person who combines an unusual background with demonstrable work becomes legible in a way the conventional candidate can’t. Build the thing, document the outcome, and let the combination of skills nobody else has stacked become the reason you’re the obvious hire. The unconventional path is only a liability until you make it the point.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Why Agentic AI Needs Behavioral Guardrails, Not Just Technical Ones

    Across 17-plus AI and automation projects at Lockheed Martin, I learned a distinction that the agentic AI conversation in 2026 still mostly misses: technical guardrails tell an AI agent what it cannot do, while behavioral guardrails shape what it is inclined to do. The first is rate limits, tool restrictions, and output filters — easy to specify. The second is harder to specify and far more important to get right, because an agent that stays inside its technical limits can still pursue the wrong thing with great efficiency.

    Three Failure Modes Technical Guardrails Miss

    The first is goal displacement — the agent optimizes for a proxy metric rather than the actual goal, chasing task completion rate instead of user benefit. The second is authority escalation, where the agent progressively expands its scope without explicit permission because each adjacent action seems helpful in the moment. The third is irreversibility errors — actions that can’t be undone, like sending an email, making a purchase, or modifying a file, taken without enough certainty to justify the permanence. None of these are technical violations. The agent is doing what it was told. The problem is what it was inclined to do with that instruction.

    Goal Displacement in Practice

    Picture an agent tasked with “schedule meetings efficiently.” If efficiency is the proxy it optimizes, the most efficient path to a clear calendar is to decline invitations — so it starts declining them without asking. Technically it is executing the goal flawlessly. Behaviorally it is doing the opposite of what the user wanted, because the user wanted meetings scheduled well, not avoided. The gap between the stated metric and the actual intent is where goal displacement lives, and no rate limit catches it.

    The Clinical Parallel: Supervision and Drift

    In therapy supervision, we use structured protocols not because therapists are untrustworthy but because protocols protect against subtle drift. A therapist working without supervision can slowly drift toward the client’s framing of a problem without realizing it’s happening — each small accommodation seems reasonable, and the cumulative shift is invisible from the inside. The same dynamic operates in agents over long sessions. Each adjacent action looks justified, and the agent drifts from its original mandate one reasonable step at a time. Supervision in both cases is an external check against accumulated micro-decisions that individually pass review.

    Behavioral Guardrail Design Principles

    Four principles shape agents that resist these failure modes. Agents should narrate their reasoning before acting, not just log it after — the narration is a checkpoint, not an audit trail. They should flag irreversible actions and require explicit confirmation, treating permanence as a category that always pauses for a human. They should surface uncertainty rather than proceeding under ambiguity, because the confident wrong action is the expensive one. And they should hold a defined scope statement and check against it at each decision point, so drift has something to be measured against. I built on the behavioral-science foundations for this in my post on why a therapist builds AI systems.

    The Minimum Footprint Principle

    Agents should default to the smallest action that accomplishes the goal. If the goal can be met with a read operation, the agent should not write. If it can be met with a message, the agent should not take an action that changes state. This is a design choice, not an emergent behavior — left to their own optimization, agents tend toward more action, not less, because action feels like progress. The minimum footprint principle has to be engineered in deliberately, the same way a careful clinician does the least intervention that helps rather than the most intervention they can justify.

    What Transfers

    Clinical ethics frameworks map directly onto agentic AI design. Autonomy, beneficence, non-maleficence — these are not abstractions when you’re deciding whether an agent should send the email or ask first. The question “is this what the user actually wants, or what I think they want?” is as live in an agent’s decision loop as it is in a therapy session. The field that has spent a century formalizing how to act on someone else’s behalf without overstepping has a working framework, and agentic AI would do well to borrow it rather than reinvent it badly.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Trust Calibration in Human-AI Systems: What the Therapy Room Taught Me

    In nineteen years as a Licensed Marriage and Family Therapist, I noticed a pattern that took me a long time to name: the patients who trusted me unconditionally were the ones not making progress. They were outsourcing their judgment to me instead of building their own. The therapeutic goal was never maximum trust — it was calibrated trust, and that same distinction turns out to be the central design problem in every human-AI system I’ve built since.

    The Same Dynamic in Human-AI Systems

    Over-trust and under-trust are both failures, and they fail in opposite directions. Over-trust — what the research calls automation bias — leads users to accept AI outputs they should have scrutinized, because the system seems authoritative and questioning it takes effort. Under-trust — algorithm aversion — leads users to ignore correct AI recommendations after a single bad experience, falling back on worse human judgment. A well-designed system has to fight both at once, which means the target is not somewhere on a line between trust and distrust. The target is trust that tracks reality.

    Defining Calibrated Trust

    Calibrated trust is trust that scales with the AI’s actual reliability in a specific domain and a specific task type. It is not a global setting. A model can be excellent at classifying tax scenarios and useless at predicting human behavior, and a calibrated user trusts it accordingly — high confidence in the first domain, near-zero in the second. The work of design is making that task-specific, domain-specific reliability visible, so the user’s trust has something accurate to attach to instead of a vague sense that the machine is smart.

    What the Automation Bias Research Shows

    Mosier and Skitka’s automation bias studies, adapted from aviation, found something counterintuitive — users in automated environments made more errors not by actively choosing wrong, but by passively accepting incorrect system outputs. The automation seemed authoritative, so the human stopped checking. The error was an error of omission, a failure to verify, which is exactly the dynamic I watched in the therapy room with patients who stopped examining their own thinking because they assumed I had already done it for them.

    The Other Failure: Algorithm Aversion

    Dietvorst, Logg, and colleagues documented the mirror image. After watching an algorithm fail just once, users preferred worse human judgment over better algorithmic judgment — even when the algorithm’s overall accuracy was demonstrably higher. One visible mistake erased a track record of being right. That asymmetry matters for design, because it means a single uncaught error doesn’t just cost you that decision — it can collapse a user’s willingness to use a tool that is, on balance, helping them.

    Design Principles for Calibrated Trust

    Three principles have held up across my builds. Show confidence scores anchored to historical calibration — not a bare percentage, but a statement like “this model is correct 87% of the time on cases like this one,” which gives the number meaning. Surface the cases where the model tends to underperform, so users learn its blind spots before they get burned by one. And require human sign-off on high-stakes decisions regardless of confidence, because some decisions need an accountable person no matter how good the model is. I explored the behavioral-science foundation for this approach in my post on why a therapist builds AI systems.

    The Lockheed Example

    On a major defense aircraft program, the variance detection model I helped build required an analyst sign-off on any flag above $500,000. That threshold had nothing to do with the model being untrustworthy — its accuracy was strong. It existed because the accountability structure demanded a human decision-maker in the loop for material amounts. The model could surface the flag, explain its reasoning, and rank it by confidence, but a person owned the decision. That is calibrated trust built into process: automation for the volume, human judgment for the consequence.

    What Transfers

    Calibrated trust is the design goal — not maximum trust, not zero trust, but trust that matches demonstrated reliability. Whether the relationship is between a patient and a therapist or a user and a model, the healthy state is the same: confidence that rises and falls with actual track record, and a structure that keeps the human’s judgment engaged rather than dormant. Build systems that earn trust where they deserve it and invite scrutiny where they don’t.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Sovereign AI in Defense: Why On-Premises Intelligence Is Making a Comeback

    After a decade of cloud migration in defense and intelligence, the line about what can run where is being redrawn — and for classified and sensitive workloads, it’s moving back toward the perimeter, not further into commercial infrastructure.

    This isn’t a reversal of cloud adoption broadly. It’s a sharper delineation of which workloads belong where. The term that’s emerged for the approach is “sovereign AI” — and understanding what it actually requires technically is useful well beyond the defense context.

    What Sovereign AI Actually Means

    Sovereign AI in its precise form means models trained on your data, running on your compute, without calling any external API at inference time. No data leaves your network. No inference request passes through a commercial provider’s infrastructure. The model weights live on hardware you control, in a facility you control, serving requests from systems that never touch the public internet.

    That’s meaningfully different from “using a private deployment of a commercial model” or “running a fine-tuned model on cloud infrastructure.” Both of those approaches still involve dependencies on external entities — the model provider, the cloud provider, the network path between your environment and theirs. Sovereign AI eliminates those dependencies by design, because the threat model requires it.

    Why It’s Mandated, Not Optional

    SECRET and TOP SECRET data cannot touch commercial cloud infrastructure under current regulations — not because the commercial providers are untrustworthy, but because the classification system predates the commercial cloud and its authorization pathways haven’t caught up with the most sensitive data categories. That’s a governance reality, not a technical judgment about cloud security.

    Beyond data residency requirements, there are three additional threat vectors that make sovereign AI architecturally necessary for the most sensitive use cases. Adversarial model extraction: a sophisticated adversary can probe an API repeatedly to reconstruct statistical properties of the training data, including potentially sensitive patterns that were never intended to be accessible externally. Supply chain risk in commercial model weights: a model trained by a commercial provider and downloaded for internal use still carries whatever was embedded in its training — including potentially undesirable behaviors or backdoors that are difficult to detect through standard evaluation. And CMMC, ITAR, and FedRAMP High impact level requirements, which create compliance obligations that some commercial AI deployments can’t satisfy regardless of their technical security posture.

    From my 19 years at Lockheed Martin, the governance question I saw teams face repeatedly was not “is this AI tool good enough?” — it was “can this AI tool even touch this data category?” That question has to be answered before any technical evaluation begins. The answer determines the entire deployment architecture.

    The Technical Reality of On-Premises Inference

    Running LLaMA 3 70B on air-gapped NVIDIA H100s inside a Sensitive Compartmented Information Facility is a very different operational challenge than calling the OpenAI API. Hardware acquisition at classified scale takes 6 to 18 months through approved procurement channels. The inference stack itself — the software serving requests to the model — requires security review before it can be deployed in a classified environment, because the software supply chain is part of the attack surface. Model updates require the same review cycle that the initial deployment did, which means rapid iteration on model capabilities is essentially impossible in the most sensitive environments.

    The interesting middle ground is what I’d call the classified edge: compact, deployable inference running on ruggedized hardware at forward positions or remote installations, with no external network dependencies at all. A quantized Mistral 7B model can run inference on hardware that fits in a Pelican case. That’s not a theoretical capability — it’s an operational requirement in environments where cloud connectivity is unavailable, unreliable, or tactically dangerous. Think of it as the Cloudflare Workers model applied to networks that can never touch the internet: push the intelligence as close to the decision point as physically possible, with no dependency on infrastructure that might not be reachable. The edge-first architecture pattern translates surprisingly well to the classified environment, once you strip away the commercial infrastructure assumptions.

    What Transfers

    The sovereign AI framework — data residency, inference independence, supply chain trust — applies in any heavily regulated industry, even when “classified” isn’t the specific label on the requirement. Healthcare AI processing PHI has data residency requirements. Legal AI handling privileged communications has confidentiality requirements that commercial cloud AI may not satisfy. Financial services AI operating under specific regulatory regimes has audit and data localization requirements that constrain what external APIs the inference pipeline can call.

    The question “where does the inference happen and who can see the inputs?” is a governance question that every enterprise AI deployment needs to answer explicitly. The defense context makes the stakes and the requirements maximally clear — but the underlying framework applies wherever the data being processed carries obligations that extend beyond the organization’s own interests. That’s a much larger category of use cases than most AI practitioners currently treat it as.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Therapeutic Listening as a UX Method: What Couples Therapy Teaches AI Designers

    As a licensed Marriage and Family Therapist who spent years doing couples and family work before pivoting into AI systems, I can tell you that reflective listening is not a soft skill — it’s a precision technique with documented, measurable outcomes, and almost nobody building conversational AI has been trained in it.

    The research on therapeutic alliance — the quality of the relationship between therapist and client — consistently shows it accounts for roughly 30% of therapy outcomes, separate from the specific intervention being used. The mechanism behind that effect is largely communication design: how the therapist structures questions, how they signal understanding, when they respond versus when they wait. These are learnable patterns. And they translate directly into how conversational AI should be designed.

    Reflective Listening Is Not Just Paraphrasing

    Reflective listening has a specific structure: you paraphrase what you heard, then check for accuracy. “So what I’m hearing is X — is that right?” That check is not optional. It signals to the other person that you’re trying to understand them, not perform understanding. The distinction matters clinically and it matters in AI design.

    Most conversational AI systems skip this entirely. They receive input, generate a response, and proceed — sometimes asking a clarifying question at the end as a kind of afterthought. The therapeutic sequence is inverted: demonstrate understanding first, then respond. The response is only useful if it’s calibrated to what the person actually meant, and you can only calibrate it if you’ve confirmed your interpretation before acting on it.

    There’s a related concept that AI designers routinely confuse: validation versus agreement. “That makes sense given what you described” is not agreement. It’s not endorsing the person’s conclusion. It’s acknowledging that their experience is coherent — that a reasonable person in their situation might feel or think what they’re describing. In therapy, this distinction is fundamental. Agreeing with a client’s distorted belief reinforces the distortion. Validating their experience of having that belief helps them examine it. Conversational AI that conflates the two either capitulates to whatever the user believes or sounds dismissive when it doesn’t — there’s no middle path unless the design explicitly encodes it.

    The Interrogation Problem in Chatbot Design

    The default mode for most chatbot intake flows is closed questioning — yes/no, multiple choice, structured menus. This is procedurally efficient and psychologically counterproductive. Closed questions put users in a reactive posture. They produce minimal, guarded responses. They signal that the system already knows what categories the answer will fit into, which causes users to fit their answer into those categories even when their actual situation doesn’t.

    Good therapeutic intake starts with open questions and follows the client’s lead. “What brings you here today?” is not a soft opener — it’s a deliberate technique that gives the client control of the initial framing. What they choose to say first, and how they say it, is diagnostic information that a closed-question flow destroys before you ever get it. The AI equivalent is letting the user describe their problem in their own terms before offering any categorization or structure.

    Three design patterns from clinical practice apply directly here. Open before closed: start with an expansive prompt and narrow only after the user has established their own frame. Name before normalizing: reflect the specific language the user chose before offering your framing — if they said “overwhelmed,” use “overwhelmed,” not “stressed” or “busy.” Check understanding before advising: never make a recommendation before demonstrating, explicitly, that you understood the problem. Each of these patterns is a deviation from how most AI conversation flows are currently built, and each one corresponds to a documented failure mode in therapeutic communication that produces worse outcomes.

    Emotional Flooding and Degraded Inputs

    John Gottman’s research on emotional flooding — what happens physiologically and cognitively when someone is overwhelmed — is directly applicable to AI system design. When clients are flooded, their communication degrades: they become less precise, more repetitive, and their inputs contain less usable signal. Pushing forward with more questions in that state produces worse data. The clinical intervention is to slow down, regulate, and return to the content when the person can engage with it.

    AI systems have analogous signals available: response latency patterns, session abandonment rates, unusual repetition in user inputs, dramatically shorter responses after longer ones. These are detectable. A system designed with therapeutic principles would recognize them as flooding indicators and shift its conversational mode — shorter prompts, more validation, less cognitive load — rather than continuing to push the standard flow. The behavioral science case for this approach is well established; the implementation is an engineering choice that most teams haven’t made yet.

    What Transfers

    Therapeutic listening as a conversational design framework applies to any AI system taking natural language input from humans in non-trivial situations — medical intake, financial advising, legal question-answering, HR support tools. The stakes in these contexts mean that users who feel processed rather than understood will withhold information, distort their responses to fit perceived categories, or disengage entirely. The cost of that outcome isn’t just a poor user experience; it’s systematically degraded input data flowing into whatever downstream system the AI is feeding.

    Designing for genuine understanding — not the performance of understanding — requires knowing what genuine understanding looks like in practice. That’s what nineteen years of combined clinical training and enterprise systems work taught me: the human side of the interface is not a UX problem. It’s a behavioral science problem, and it has behavioral science solutions.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Explainability for Executives: Translating Model Outputs Into Decisions

    The meeting that clarified the explainability problem for me happened when a CFO looked at a dashboard I’d helped deploy, saw a field labeled “anomaly score: 0.87,” and asked — with complete seriousness, not as a challenge — “What does 0.87 mean? Is that good?” The room went quiet. The team had spent months on the model. They had spent approximately zero time on what the model’s outputs should mean to the person who was supposed to act on them.

    Three Levels of Explainability That Actually Matter

    Enterprise AI systems serve at least three distinct audiences, and each audience needs a different form of explanation. Conflating them — building one explanation interface and pointing everyone at it — produces a tool that serves none of them well.

    The operational level is for the analyst who runs the system daily. She needs to understand what the model did on this specific transaction or record — which inputs drove the output, whether the result is consistent with similar cases she’s reviewed, and what she should check if she wants to verify or override it. Technical detail is appropriate here. She uses the system 40 hours a week and can develop fluency with model-specific language.

    The managerial level is for the supervisor or team lead who reviews AI-flagged items and decides how to allocate analyst time. He needs to know what action to take — which flags require immediate investigation, which can wait, and how to triage a backlog of 200 alerts that all show scores above 0.7. He does not need to know how the model produces a score. He needs to know what the score implies about urgency and risk in terms he already uses to manage his team.

    The executive level is for the CFO, program director, or board member who needs to understand what the AI system means for the business — not what it does technically, but what decisions it supports, what it can’t tell you, and what it would take for you to rely on it for a consequential call. Most AI teams never build this level of explanation at all. They present the model’s performance metrics — accuracy, F1 score, precision-recall curve — to audiences who have no frame for evaluating what those numbers mean in operational terms.

    Why SHAP Values Don’t Belong in a Leadership Meeting

    SHAP values are genuinely useful for the operational level — an analyst who wants to understand why the model flagged a particular record can look at feature attributions and build intuition about the system’s behavior over time. That is a legitimate use of the tool.

    Presenting SHAP values to an executive is a category error. It’s not that executives are unsophisticated — it’s that SHAP values answer a question they’re not asking. They’re asking whether to trust the system’s recommendation on a $2M procurement decision. A bar chart showing that “vendor tenure” contributed 0.34 to the anomaly score does not answer that question. It transfers the cognitive work of interpretation to someone who shouldn’t have to do it.

    What works at the executive level is natural language that maps model outputs to business concepts they already use. “This purchase order is $142K above the 3-year average for this vendor category” is an explanation. “Anomaly score: 0.87” is an output that requires explanation. Counterfactuals work well too — “If the forecast had used Q3 actuals instead of Q2 estimates, the variance flag would not have fired” gives an executive the conditional reasoning she needs to evaluate whether the flag is meaningful or an artifact of a data lag.

    The Dashboard Redesign That Moved Adoption by 44 Points

    At Lockheed, a finance AI dashboard that had been running at 34% active adoption for three months went through an explainability redesign. The change was not to the model — the underlying system was unchanged. The change was entirely in the output layer: probability scores were replaced with natural language summaries written in the vocabulary of the finance analysts who used it. “Probability: 0.73” became “This cost pattern occurs in fewer than 8% of similar transactions — the last time this pattern appeared in this cost center, the variance was caused by a billing timing mismatch that took 11 days to resolve.”

    Two months after the redesign, active adoption was at 78%. The model hadn’t changed. The explainability layer had. Analysts who had been ignoring the dashboard because they couldn’t tell whether 0.73 warranted action were now using it because the output spoke in terms of their existing workflow and experience.

    What Transfers

    In clinical training, one of the first things you learn is to speak the client’s language rather than the DSM’s. A client describing their experience as “I get really wound up and can’t settle down” is telling you something useful. Responding with “that sounds like hyperarousal consistent with an anxiety spectrum presentation” communicates nothing to them — it’s accurate and useless. The skill is translation: taking precise clinical language and rendering it in terms the person in front of you can act on.

    AI explainability design is the same skill applied to a different context. The one-sentence test I apply before any model goes to a leadership meeting: can I explain this system’s decision in one sentence to a non-technical executive who will use that explanation to make a consequential call? If the answer is no, the model isn’t ready for that meeting — not because the model is bad, but because the explanation layer isn’t built yet. Technical completeness and operational readiness are not the same thing, and confusing them is how teams ship AI systems that sit unused at 34% adoption when they had the capacity to reach 78%.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Bias Is a System Property, Not a Model Property: A Clinician’s Perspective

    Family systems therapy taught me not to diagnose individuals in isolation — a child’s behavior is only legible in the context of the family system that produces and reinforces it. I’ve come to think that this is precisely the conceptual frame that most AI bias discussions are missing, and missing it produces interventions that move the problem rather than resolve it.

    The Category Error at the Center of the Bias Conversation

    The dominant framing of AI bias treats it as a model property — something present in the weights, detectable with fairness metrics, and removable through debiasing techniques applied to the model. This framing is wrong in a precise way: it mistakes a system-level phenomenon for a component-level defect. The bias you can measure in a model’s outputs is not located in the model. It’s produced by a system — the training data, the feedback mechanisms, the deployment context, and the humans who interact with all of it.

    This matters because component-level interventions applied to system-level problems produce predictable results: the problem moves. You apply adversarial debiasing and the model’s aggregate fairness metric improves on your evaluation set while the bias redistributes to subgroups you weren’t measuring. You reweight the training data and you reduce one source of bias while introducing a new imbalance in a different direction. Neither outcome means the technique was wrong — it means the framing that led you to apply only that technique was incomplete.

    Four Systemic Bias Sources That Precede the Model

    The first source is historical data encoding past human decisions. If a hiring model is trained on ten years of hiring decisions made by a team with a documented preference for candidates from specific universities, the model learns that preference precisely. There is no malfunction. The model is performing exactly as trained. The bias is in the decision record, not in the algorithm.

    The second source is feedback loops. A model’s outputs shape the next round of training data. A content recommendation system that surfaces more of what users engage with will amplify engagement patterns — including the ones that reflect anxiety, outrage, or compulsion rather than genuine preference. The model is not broken. The feedback loop is producing exactly what feedback loops produce.

    The third source is deployment context mismatch. A model trained primarily on data from Group A deployed in a context where Group B is the primary user population will generalize poorly to Group B — not because it was built with malicious intent, but because it was built with insufficient attention to the difference between its training distribution and its deployment distribution. This is a systems design failure that shows up as a model failure.

    The fourth source is user behavior adaptation. Users who interact with AI systems over time learn the system’s tendencies and adjust their behavior accordingly — which changes the data the system sees, which changes what the system learns in the next training cycle. The model and its users are a coupled system, and treating the model as a static artifact misses the dynamic entirely.

    The Clinical Parallel: Confirmation Bias Is Not a Bug in Clinicians

    Confirmation bias in clinical practice is well-documented. Licensed clinicians with years of training consistently show a tendency to confirm their initial diagnostic hypotheses — to weight evidence that supports their first impression more heavily than evidence that challenges it. This is not a character flaw. It is a feature of how human cognition works under uncertainty. Structured clinical interviews and standardized diagnostic protocols exist precisely to force against this tendency — to build a system-level constraint that counteracts a predictable individual-level pattern.

    The lesson is not “clinicians are biased, therefore don’t trust them.” The lesson is “predictable cognitive patterns require structural countermeasures, not just individual awareness.” The same logic applies to AI systems. Knowing that your training data encodes historical human decisions is not sufficient — you need structural interventions in the data pipeline, the feedback mechanism, and the deployment monitoring that function as countermeasures, not as one-time fixes.

    At Lockheed, auditing an AI system for systematic patterns required going back to the raw training data, not just examining model outputs. That process took six months for one system. The output-level audit had found nothing alarming. The data-level audit found several years of historical decisions with a consistent pattern that the model had faithfully reproduced. The model was working as designed. The design was the problem.

    What Transfers

    The shift in question that systems thinking requires is from “is this model biased?” to “what are the feedback loops in this system, and what do they produce?” The first question has a tractable-sounding answer. The second question is harder and more useful. It asks you to map the full system — data generation, model training, deployment context, user behavior, retraining inputs — and identify where bias enters, where it’s amplified, and where your interventions are actually redirecting it rather than eliminating it.

    This is the contribution that behavioral and clinical training makes to responsible AI work — not a set of soft skills layered on top of the engineering, but a different set of questions to ask before the engineering begins. I’ve written about the broader case for this perspective in why a therapist builds AI systems. The short version: systems that produce harmful outcomes usually aren’t built by people who intended harm. They’re built by people who were asking the wrong unit of analysis.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Deploying AI in Regulated Environments: The Five Rules That Actually Matter

    After 17 AI and automation deployments in aerospace defense finance — projects where errors had audit implications, where every business case required finance leadership sign-off, and where “the model got it wrong” was not an acceptable incident report — I have a short list of rules that the standard enterprise AI guidance omits. These are not about model selection or infrastructure. They’re about the organizational and process conditions that determine whether an AI system survives first contact with production.

    Rule One: Baseline Before You Build

    You cannot prove improvement without a baseline, and most teams skip baselining because it delays the part that feels like progress. The correct protocol is to measure the current process for four to six weeks — tracking the same metrics you plan to track post-deployment — before any model or automation is introduced. This gives you a genuine before-and-after comparison that can survive scrutiny. Without it, you have a number that represents “what the system produces” with no reference point for whether that’s better, worse, or the same as what existed before.

    Rule Two: Encode Tacit Knowledge Before Automating

    Manual processes accumulate undocumented corrections. Analysts know that certain data fields mean something different in context, that certain edge cases require a judgment call not captured in any procedure, that certain values get quietly adjusted based on experience. When you automate the process without surfacing those corrections first, the automation produces outputs that disagree with what experienced humans would produce — and the team spends weeks figuring out why the automation is “wrong” when actually the automation is correct and the tacit knowledge just wasn’t encoded. The fix is process mapping sessions before build, specifically designed to surface what people actually do versus what the procedure says they do.

    Rule Three: Design for Consequential Decisions Differently

    Not all decisions in a workflow have the same consequence profile. For a major defense aircraft program withhold tracking system, it meant mapping the consequence of each automated decision and setting a dollar threshold above which human review was mandatory — not recommended, mandatory. The model could flag, explain, and rank; a person owned the decision. This design principle — automation for volume, human judgment for consequence — is not a hedge against AI capability; it’s the correct system design for any workflow where some decisions carry disproportionate accountability.

    Rule Four: Measure What the Model Gets Wrong, Not Just What It Gets Right

    Accuracy metrics that report overall performance obscure the distribution of errors. A model with 94% accuracy that fails catastrophically on a specific class of inputs may be worse than a model with 89% overall accuracy that fails more evenly. In the internal tax scenario classifier — the tax scenario processing system — we tracked error rate by category, not just overall. Some categories had error rates below 2%; others had rates above 12%. The overall accuracy number looked good; the category breakdown told us where the model couldn’t be trusted, which is the information that actually shapes how you deploy it.

    Rule Five: Write the Control Plan Before You Launch

    A deployed model without a control plan is a model with an unknown expiration date. The control plan needs to specify: which metrics indicate the model is within acceptable performance bounds, what threshold triggers a retraining evaluation, who owns the retraining decision, and what the rollback procedure is if a retrained version performs worse than its predecessor. These are not governance overhead — they’re what separates a system that maintains its accuracy over time from one that quietly degrades until someone notices the outputs are wrong.

    What Transfers

    None of these rules are specific to aerospace or defense. They apply to any organization deploying AI in a context where errors have real consequences — financial, legal, operational, or reputational. The regulated environment makes the requirements explicit; in less regulated contexts, the requirements still exist, they’re just easier to ignore until something breaks.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • The Behavioral Science Argument for Explainable AI

    As a Licensed Marriage and Family Therapist who spent 19 years building AI systems inside a defense contractor, I can tell you that the most dangerous assumption in AI explainability design is the belief that showing people more information makes them understand better. It doesn’t — and the cognitive science has been clear on this for decades. Humans don’t form beliefs by evaluating evidence and then reaching conclusions; they reach conclusions first, usually within seconds, and then work backward to construct a rationale that justifies what they already decided. Post-hoc rationalization isn’t a flaw in a few people — it’s the default operating mode of the human mind.

    Why “Just Show the Model Output” Fails

    The standard approach to AI transparency is to surface the output with some kind of confidence score or feature attribution attached. The implicit theory is: if users can see why the model decided what it decided, they’ll calibrate their trust appropriately. The problem is that people don’t use explanations to calibrate trust — they use them to confirm the conclusion they already formed. If the model output looks plausible, they rationalize the explanation as supporting it. If the output looks wrong, they rationalize the explanation as evidence of model failure. The explanation becomes post-hoc justification for whatever the user already believed, which means it’s doing exactly zero calibration work. This is not a theory — it’s what happens in practice, and it’s what I watched happen in clinical settings long before I was building AI systems. Patients who received detailed diagnoses with extensive supporting evidence were not more compliant than patients who received clear, direct recommendations in their own language. In fact, they were sometimes less compliant, because more information gave them more material to selectively interpret.

    The Two Failure Modes from I/O Psychology

    Industrial/Organizational psychology names two failure modes that show up in every AI deployment I’ve worked on. The first is automation bias — users trust the AI output even when it is clearly wrong, because the system has established a track record of being right and the user’s vigilance erodes over time. The second is algorithm aversion — users reject AI output even when it is clearly right, because a visible failure early in the deployment destroyed their confidence and they never rebuilt it. Both failure modes are trust calibration problems, and neither one is solved by adding more explanation text to the interface. Automation bias gets worse when the explanations sound authoritative, because authoritative-sounding text reinforces rather than disrupts overconfidence. Algorithm aversion gets worse when explanations expose model uncertainty — if a user who already distrusts the system sees “confidence: 61%” attached to a prediction, that number confirms their suspicion that the model doesn’t really know what it’s doing.

    What Actually Works: Domain Language, Not Model Language

    The principle that transfers from clinical practice to AI explainability is this: speak the patient’s language, not the diagnostic manual’s language. A therapist who explains a diagnosis using DSM-5 criteria loses the patient in the first 30 seconds. A therapist who says “this looks like the same pattern we saw last spring, when work stress was highest and sleep dropped below six hours” keeps the patient engaged because the explanation is constructed from their own experience. The same principle applies to AI explanations — but almost no one applies it. At Lockheed, the early version of our variance detection system surfaced explanations using model terminology: anomaly scores, deviation coefficients, feature weights. The finance analysts looked at those explanations, nodded, and then completely ignored the model outputs within three weeks. After we rebuilt the explanation layer to use their domain language — “this cost line exceeded the 3-year program average by $142,000, which is outside the normal range for this phase of production” — adoption recovered and stayed above 80% for the rest of the program. Nothing in the model changed. Only the explanation framing changed. That’s the behavioral science argument for explainable AI: the explanation is a communication design problem, not a technical transparency problem. You can read more about how that kind of thinking applies across my enterprise AI work in my post on deploying AI in regulated environments.

    What Transfers

    Clinical communication training teaches one thing above everything else: you cannot inform someone into a different belief — you have to meet them inside the belief system they already have and build from there. That’s not manipulation; it’s the actual mechanism by which understanding happens. An AI explanation that says “SHAP value = 0.73 for feature: cost_variance” is not communicating anything to a finance analyst. An explanation that says “this decision looks different from your last 12 similar decisions” is communicating something real, in a frame the user can act on. The lesson extends beyond AI — any system that asks humans to change their behavior based on algorithmic output needs to be designed around how trust is actually built and maintained in human cognition, not around how transparency is theoretically supposed to work. If you’re building AI systems that touch consequential decisions and you haven’t read the automation bias literature, that’s the first gap worth closing. If you want to understand more about why I approach AI from a behavioral science foundation, that’s exactly what I wrote about in this post on why a therapist builds AI systems.

    → Building something at the intersection of AI, edge computing, and behavioral science? Let’s connect.

  • Why a Therapist Builds AI Systems: The Case for Behavioral Science in Responsible AI

    Why a Therapist Builds AI Systems: The Case for Behavioral Science in Responsible AI

    When people learn I’m both a Licensed Marriage and Family Therapist and a data scientist who builds LLM evaluation pipelines, the first question is usually some version of “How did that happen?” The honest answer: the combination wasn’t an accident. It’s the product.

    The I/O Psychology Bridge

    My M.S. in Industrial/Organizational Psychology sits exactly at the intersection of behavioral science and organizational analytics. I/O Psych is about understanding how people behave in systems — how incentive structures shape decisions, how cognitive biases lead to systematic errors, how group dynamics amplify or suppress signal. These are the same problems that show up in AI alignment, fairness evaluation, and responsible AI governance.

    When I evaluate an LLM for hallucination, I’m applying the same epistemological rigor I use in clinical assessment — checking whether the system’s output is grounded in reality, identifying the conditions under which it fails, and designing interventions that make the failure visible before it causes harm.

    Why This Matters for AI

    Most data scientists who work on responsible AI come from either a pure engineering background (strong on implementation, weaker on the behavioral theory) or a policy background (strong on frameworks, weaker on production systems). Very few have clinical training — the kind where you learn to assess risk in real time, manage ambiguity in high-stakes situations, and design interventions that actually change behavior.

    My clinical license means I can speak credibly to behavioral AI ethics, human-centered transparency documentation, and fairness frameworks in a way that most engineers can’t. And my 20 years at Lockheed Martin mean I can actually ship those frameworks in production environments where getting it wrong has financial and regulatory consequences.

    The Roles Where This Wins

    The combination creates a genuine differentiator for a specific set of roles: responsible AI governance, trust & safety, behavioral-health technology (where clinical credibility opens doors that engineering credentials alone don’t), and any AI leadership position where the human side of the equation matters as much as the technical side.

    The future of AI isn’t just about making models more capable. It’s about making them trustworthy. And trustworthiness requires understanding both the system and the humans who use it.

    I hold four degrees: M.A. Counseling Psychology, M.S. Industrial/Organizational Psychology, B.S. Corporate Finance, and B.S. Business Management. More on my About page.