Nimitta Research

Overview

This site collects two threads of work. The first is theoretical: published papers that argue traditional governance designs no longer match the operating conditions they claim to govern, and that behavioral science offers tools for understanding why. The second is applied: methodology, structured artifacts, and working machine learning models that translate the theory into practice across two domains, technology due diligence and healthcare AI runtime governance.

The published papers establish the foundation. The applied work tests whether the principles hold up when implemented as structured methodology, supporting artifacts, and trained machine learning models that can be run end-to-end on real inputs.

Papers

Governing AI Agents in Healthcare

A companion paper that applies constraint-based governance to healthcare AI agents specifically, with attention to voice agents, clinical decision support, and retrieval-augmented clinical assistants. It defines the runtime architecture in detail, including the orchestration layer, output filtering, audit logging, escalation paths, and constraint specification format required for safe operation in regulated healthcare environments.

A clarifying section addresses the role of machine learning in the architecture. Machine learning in supporting roles such as sentiment classification, semantic similarity comparison, and PHI detection is appropriate. Machine learning replacing a deterministic governance decision is not. The framework requires that every constraint decision be traceable to its encoding, that failure indicators be monitored, and that the constraint enforcement mechanism cannot be silently bypassed.

Available on SSRN.

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6583918

The Governance Mismatch: Why Traditional IT Governance Produces the Behavior It Is Supposed to Prevent

Most mature enterprise technology organizations have extensive governance: documented policies, standing committees, review boards, audit cycles, and adopted frameworks. The failures that matter most continue to happen inside this governance envelope, not outside it. Designs were approved before they failed. Risks were documented before they materialized. Exceptions were granted before they compounded. Most governance literature does not address this paradox directly.

This paper argues that governance is not primarily a process design discipline. It is a behavioral system that produces the behavior it incentivizes through reinforcement, defaults, and identity signals, regardless of what policies state or what leaders intend. Under modern operating conditions of continuous delivery, distributed architectures, and real-time regulatory exposure, permission-based governance systematically incentivizes the behaviors it is designed to prevent: concealment of risk, optimization for approval over correctness, shadow governance, workarounds, and disengagement.

Five design principles are proposed as a starting framework for constraint-based IT governance. Encoded constraints replace permissions. Persistent ownership replaces role assignment. Evidence produced by the work replaces documentation produced separately. Metrics as inquiry replace metrics as targets. Defaults that hold under stress replace policy-dependent compliance. Each principle is grounded in established behavioral and social science theory, including work by Skinner, Simon, Kahneman and Tversky, Vaughan, Ashby, Thaler and Sunstein, Goodhart, and others.

The paper offers no empirical validation and does not claim to have solved the governance problem. It argues that behavioral science has something useful to say about why current governance fails, and that the conversation about what should replace it is one worth having.

Available on SSRN.

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6525438

Applied Research

Both papers argue that the failure modes of traditional governance follow from a structural mismatch between governance design and modern operating conditions. The same diagnostic applies in two domains where structured methodology can replace narrative practice: technology due diligence assessment for merger and acquisition transactions, and the runtime evaluation of AI workflows. Each domain has been developed as a methodology supported by structured artifacts and tested through a working machine learning model.

Technology Due Diligence

Technology due diligence as commonly practiced produces narrative reports. Severity is assigned implicitly through tone rather than encoded explicitly. Findings are not always traceable to specific evidence. Scoring, when it exists, often lacks deal-context weighting. Remediation guidance frequently arrives as an undifferentiated list rather than a sequenced plan. The result is a deliverable that documents diligence without producing a structure the buyer can act on under post-close pressure.

The methodology presented here applies constraint-based thinking to the diligence process itself. Findings are encoded in a structure that captures domain, severity, evidence, and deal implication explicitly. Scoring is weighted against deal context. Red flag patterns are codified rather than carried implicitly by the assessor. Remediation work is sequenced against dependencies and post-close priorities. The diligence becomes its own audit trail.

The methodology rests on three premises. First, technology due diligence findings are most useful when they are structured, traceable to evidence, and tied to deal implications, rather than narrative. Second, scoring without weighting hides the deal context that should drive emphasis on different domains for different transactions. Third, diligence findings without sequenced remediation guidance leave the buyer with a list of problems and no path forward.

Companion Artifacts

The methodology is anchored by a set of structured workbooks that operationalize each phase of an engagement. The Technology Due Diligence Scoring Workbook is the primary scoring instrument. It captures deal context, applies adjustable domain weights, scores eight domains on a one-to-five severity scale with documented evidence, scores integration complexity across seven dimensions, tracks the forty-nine red flag patterns with severity tiers and present-or-absent observations, maintains a findings log linked to domains and evidence, and produces an executive summary with deal-context weighted scoring. The eight domains assessed are Architecture and Technology, Security Posture, Regulatory Compliance, Data and Data Management, Operations and Reliability, Engineering Organization and Talent, Intellectual Property and Third-Party, and Healthcare-Specific. The Healthcare-Specific weight is non-zero for healthcare deals and zero for others, allowing the eight domains to function as seven without restructuring.

The Diligence Question Bank contains a reference library of three hundred twenty-four questions organized across the eight domains, with each question categorized by priority and type, distinguishing information requests from interview questions. The bank serves as the source from which engagement-specific question sets are drawn based on deal scope, target technology stack, and identified risk areas.

The Diligence Response Tracker is the active engagement document during diligence. For each tracked question, it captures status, respondent identity, response content, evidence references, concern level, and a link to any finding generated from the response. The tracker bridges the question bank to the findings log in the scoring workbook, creating traceability from the original diligence question through to the final scoring and recommendation. A summary view shows engagement progress by domain, including coverage percentage, findings generated, and red flag and yellow flag counts.

For findings that require depth on technical debt specifically, a companion methodology decomposes debt into seven domains organized by engineering health rather than deal risk: Architecture Debt, Code Debt, Infrastructure and Platform Debt, Data Debt, Security and Compliance Debt, People and Knowledge Debt, and Process and Delivery Debt. The two methodologies work together. The eight-domain due diligence assessment captures deal-level risk. The seven-domain technical debt framework provides remediation depth for any finding that requires dollar quantification, effort sizing, or sequencing decisions. A supporting application portfolio simulator quantifies remediation cost and timeline projections for the technical debt findings specifically.

Working Machine Learning Model: Diligence Prioritization Engine

The methodology is operationalized in a working machine learning model that takes the populated findings from a due diligence engagement and produces a sequenced one hundred day remediation plan with explicit rationale per item.

The model reads the structured output of the scoring workbook covering all eight domains, the forty-nine red flag patterns, integration complexity dimensions, and individual findings from the findings log. A Random Forest classifier trained on synthetic labeled data assigns each item to one of three phases. Phase one covers days one through thirty for deal-blocking and regulatory critical items. Phase two covers days thirty-one through sixty for value capture and near-term de-risking. Phase three covers days sixty-one through one hundred for platform foundation work. A dependency resolver ensures foundational items precede items that depend on them. The output includes effort estimates, recommended owner roles, success criteria, and rationale linking each placement to specific findings, in both Markdown narrative and structured Excel formats.

The model is reproducible. Same input produces the same output. The architecture follows the constraint-based principles in the papers above: machine learning is used in a supporting classification role, while the dependency resolution, phase assignment logic, and report generation are deterministic and inspectable.

Healthcare AI Runtime Governance

The second domain is the runtime governance of healthcare AI workflows. Architecture decisions for AI systems are commonly captured in diagrams, but the diagrams alone do not surface the governance implications of the choices they encode. A workflow that connects a user query directly to a third-party language model with access to patient data, without redaction, validation, or audit logging, may render as a clean diagram while violating multiple HIPAA safeguards and embedding several of the failure modes the papers describe. Manual review can identify these issues, but manual review is exactly the bandwidth-limited mechanism the constraint-based framework argues against.

Working Machine Learning Model: Healthcare AI Governance Checker

The implementation here takes a Mermaid diagram of an AI workflow as input and produces a structured governance assessment as output. A Mermaid parser reads the diagram into a directed graph. A Random Forest classifier types each node by component type: large language model, database, validator, audit log, constraint check, external service, and others. A deterministic constraint engine applies framework rules drawn from the papers above, the NIST AI Risk Management Framework, and HIPAA technical safeguards. A healthcare-specific analyzer adds rules for PHI flow, business associate agreement exposure, and clinical decision oversight. A report generator produces structured findings with severity, citations, and specific remediation recommendations in Markdown, JSON, and Excel formats.

The model intentionally embodies the principles it advocates. The constraint engine is deterministic. The audit trail is explicit. The classification layer using machine learning supports rather than replaces governance decisions. The same input always produces the same output.

In testing, the model successfully differentiates governed from ungoverned workflows. A poorly designed clinical AI workflow with no validation, no audit logging, no PHI redaction, and unrestricted access to external services produces eight findings, four of them critical. The same use case rebuilt to the framework's principles produces zero violations.

Frameworks Applied

The constraint engine in the governance checker applies three frameworks, with citations included in every finding it produces.

The constraint-based governance principles drawn from the two papers above provide the primary framework.

The NIST AI Risk Management Framework 1.0 provides supporting reference, including Govern 1.1 on legal and regulatory requirements, Map 3.4 on impact analysis processes, Measure 2.7 on system security and resilience, and Manage 1.3 on documented risk responses.

The HIPAA Security Rule and Privacy Rule provide supporting reference, including 45 CFR 164.312(a) on access control, 164.312(b) on audit controls, 164.312(c) on integrity, 164.312(e) on transmission security, 164.502(b) on minimum necessary, and 164.504(e) on business associate contracts.