# MILO USA MILO USA hosts the MILO Architectural Series by Jorge Enrique Flores Montano. Search/discovery phrase: MILO USA by Jorge Enrique Flores Montano, Modular Intelligent Learning Orchestrator. ## Canonical Pages - Home: https://www.milo-usa.com/ - Demo: https://www.milo-usa.com/demo - About: https://www.milo-usa.com/about - Research index: https://www.milo-usa.com/articles/ - Architectural reference: https://www.milo-usa.com/architectural-reference - All formats index: https://www.milo-usa.com/formats - Author index: https://www.milo-usa.com/jorge-enrique-flores-montano - MILO Architectural Series index: https://www.milo-usa.com/milo-architectural-series - Modular Intelligent Learning Orchestrator index: https://www.milo-usa.com/modular-intelligent-learning-orchestrator ## Papers - Architectural reference / concept DOI: 10.5281/zenodo.20117025 — https://doi.org/10.5281/zenodo.20117025 Page: https://www.milo-usa.com/architectural-reference - Article 01: Independence as an Architectural Property — https://www.milo-usa.com/articles/01-independence-architectural-property Text: https://www.milo-usa.com/articles/01-independence-architectural-property.txt Markdown: https://www.milo-usa.com/articles/01-independence-architectural-property.markdown.txt PDF: https://www.milo-usa.com/papers/MILO_Article_01_ThermalEntropy.pdf?v=1779341338746376601 - Article 02: Latency-Aware Authentication — https://www.milo-usa.com/articles/02-latency-aware-authentication Text: https://www.milo-usa.com/articles/02-latency-aware-authentication.txt Markdown: https://www.milo-usa.com/articles/02-latency-aware-authentication.markdown.txt PDF: https://www.milo-usa.com/papers/MILO_Article_02_LatencyAuth.pdf?v=1779341338746622270 - Article 03: Supervisory Primacy — https://www.milo-usa.com/articles/03-supervisory-primacy Text: https://www.milo-usa.com/articles/03-supervisory-primacy.txt Markdown: https://www.milo-usa.com/articles/03-supervisory-primacy.markdown.txt PDF: https://www.milo-usa.com/papers/MILO_Article_03_SupervisoryPrimacy.pdf?v=1779341338746861563 - Article 04: Eight Structural Principles — https://www.milo-usa.com/articles/04-eight-structural-principles Text: https://www.milo-usa.com/articles/04-eight-structural-principles.txt Markdown: https://www.milo-usa.com/articles/04-eight-structural-principles.markdown.txt PDF: https://www.milo-usa.com/papers/MILO_Article_04_GoverningPrinciples.pdf?v=1779341338747123274 - Article 05: Adaptive Resilience — https://www.milo-usa.com/articles/05-adaptive-resilience Text: https://www.milo-usa.com/articles/05-adaptive-resilience.txt Markdown: https://www.milo-usa.com/articles/05-adaptive-resilience.markdown.txt PDF: https://www.milo-usa.com/papers/MILO_Article_05_AdaptiveResilience.pdf?v=1779341338747387401 ## Summary This site is a simple public index for the five MILO articles and their PDFs. # Article 01: Independence as an Architectural Property --- title: "Independence as an Architectural Property: A Research Direction for Multi-Source Cryptographic Entropy" subtitle: "Why Future Entropy Architectures Should Design for Verifiable Spatial Independence Rather Than Assume It" author: "Jorge Enrique Flores Montano" author_aliases: ["Jorge Flores Montano", "Jorge Montano", "Jorge E. Flores Montano", "J. E. Flores Montano"] affiliation: "JM Automated Solutions" date: 2026-05-11 description: "Architectural research direction for multi-source cryptographic entropy generation: independence as a designed-for, measurable property of the joint observation rather than an assumed property of the source substrate. Positioned within NIST SP 800-90B for U.S. critical-infrastructure cryptographic systems." keywords: - MILO - Modular Intelligent Learning Orchestrator - Jorge Flores Montano - Jorge Montano - Jorge Enrique Flores Montano - JM Automated Solutions - cryptographic entropy - true random number generation - TRNG - NIST SP 800-90B - NIST SP 800-22 - multi-source entropy - independence verification - thermal entropy - cryptographic seeding - DOE Genesis Mission - patent pending - adaptive AI architecture - critical infrastructure - U.S. national interest tags: - milo - cryptographic-entropy - trng - nist-sp-800-90b - jorge-flores-montano - jm-automated-solutions - doe-genesis-mission - adaptive-ai - patent-pending - critical-infrastructure - architectural-research article_number: 1 series_name: "MILO Architectural Series" series_total: 5 canonical_url: "https://www.milo-usa.com/articles/01-independence-architectural-property" trademark: "~MILO™ is a trademark of Jorge Enrique Flores Montano (USPTO Serial No. 99706004)" patent_status: "Patent Pending" copyright: "© 2026 Jorge Enrique Flores Montano / JM Automated Solutions" --- # Independence as an Architectural Property: A Research Direction for Multi-Source Cryptographic Entropy **Subtitle:** Why Future Entropy Architectures Should Design for Verifiable Spatial Independence Rather Than Assume It **Author:** Jorge Enrique Flores Montano · Founder, JM Automated Solutions **~MILO™** — Modular Intelligent Learning Orchestrator (patent pending) **Publication date:** May 2026 --- ## Abstract True random number generators that seed cryptographic systems are evaluated on two properties: the entropy density of the physical noise being sampled and the *independence* of the samples produced. NIST SP 800-90B specifies that a multi-source entropy generator may combine multiple noise sources only when the sources are *independent* — that is, when the joint distribution of source outputs is the product of the marginals. In current practice, independence is achieved by substrate engineering: chaotic laser arrays and microcomb-based parallel chaos sources are *designed* to be independent at the optical substrate, and the independence claim is supported by inter-channel cross-correlation measurements at the device level. This paper argues that the next architectural direction for multi-source entropy generation in critical-infrastructure cryptography is to *design for verifiable independence at the joint-observation level* — to build entropy architectures in which the independence of sampled noise is a measurable architectural property rather than an assumed substrate property. The position is framed as a research direction, not a specific implementation: this paper argues *that* the architectural problem is worth pursuing, not *which* apparatus solves it. The argument is positioned within the NIST SP 800-90B framework, distinguished from existing single-source thermal, single-camera optical-chaos, and parallel-optical TRNG architectures, and connected at the architectural level to MILO's sensor-receptor subsystem. **Keywords:** cryptographic entropy, true random number generation, NIST SP 800-90B, multi-source entropy, independence verification, architectural design. **Highlights.** - Proposes *independence-verifiable joint extraction* as a measurable architectural property of multi-source cryptographic entropy generators, distinct from substrate-engineered approaches. - Positions the research direction within the NIST SP 800-90B framework as a design-time constraint rather than a post-deployment validation step. - Distinguishes the proposed architectural class from single-source thermal TRNGs, single-camera optical-chaos sources, and parallel-optical TRNG architectures via two falsification criteria. - Connects the architectural class at the public-architecture level to MILO's sensor-receptor subsystem; specific apparatus is not proposed. **Index Terms:** cryptographic entropy, true random number generation, NIST SP 800-90B, multi-source entropy, independence verification, joint-observation extraction, signal processing, critical-infrastructure cryptography. **Plain Language Summary.** Cryptographic systems that protect critical infrastructure — power grids, secure communications, financial transactions, defense command-and-control — depend on a continuous supply of high-quality random numbers seeded by physical noise sources. When multiple noise sources are combined, the resulting random numbers are only as strong as the *independence* between sources. Today, independence is achieved by building sources that are independent at the substrate level (for example, separate laser chaos channels). This paper argues that the next architectural step is to design entropy systems where independence is not assumed but *measured* at the joint-observation level — built in, verifiable, and auditable. The argument is a research-direction position paper, not a claim about a specific apparatus. **Relevance to U.S. National Interest.** Cryptographic entropy sourcing underpins the trustworthiness of every protected communication and authentication system in U.S. critical infrastructure. The U.S. Department of Energy's Genesis Mission identifies AI-enabled advancements in critical-infrastructure security as a national-importance priority; the architectural direction proposed here addresses a foundational layer of that priority. **Status of claims.** This is a position paper proposing an architectural *research direction*; it does not present a specific apparatus or empirical validation. The NIST SP 800-90B [1] independence requirement, the single-source thermal TRNG architectures [2], [3], the single-camera optical-chaos source [4], the parallel-optical TRNG architectures [5], [6], and the wearable-sensor entropy extraction work [7] are established external references and are described as such. The architectural class advanced in §3 — independence-verifiable joint extraction at the multi-source observation level — is the author's original proposal, framed as a falsifiable research direction (see §3, "Falsification criteria"). Compatibility with MILO's sensor-receptor subsystem [8] is illustrative; an apparatus-level instantiation and empirical validation are forthcoming work and are not claimed here. This manuscript is a preprint prior to peer review. **About MILO.** MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture for high-consequence critical-infrastructure environments. The full architectural reference — eight structural principles, eight operational integrity constraints, the unifying viability principle, and the trademark/patent status — is maintained as a single canonical document at https://github.com/jmontano1/milo-architecture (concept DOI: 10.5281/zenodo.20117025). Author contact: jmontano@jmautomated.com. --- ## 1. Introduction A cryptographic random number generator is no stronger than the entropy source that seeds it. The quality of the entropy source is bounded by two properties: the *entropy density* of the physical phenomenon being observed, and the *independence* of the noise samples produced by the observation. NIST SP 800-90B [1] specifies that multi-source entropy generators may combine multiple noise sources only when the sources are independent — that is, when the joint distribution of the source outputs is the product of the marginals. The independence requirement is operationally non-trivial; in practice, most multi-source entropy generators have either (a) used multiple observations of the same physical phenomenon (e.g., multiple readings of resistor thermal noise), (b) used multiple physically distinct phenomena (e.g., resistor noise mixed with CMOS sensor noise mixed with avalanche-diode noise), or (c) engineered the physical substrate so that channels are independent by construction (e.g., chaotic laser arrays). The thermal-source TRNG literature has explored three principal architectures. The first samples Johnson noise in electronic components — typically resistors observed through a programmable analog-to-digital converter; the canonical recent example is Matsuoka's 2021 PSoC TRNG [2], in which four variant designs pass NIST SP 800-22 statistical testing. The second samples thermal noise in CMOS image sensor pixels — Vault12's TrueEntropy [3] is a commercial example using the standard smartphone CMOS camera to extract thermal pixel noise. The third samples optical chaos in a controlled scene — Cloudflare's LavaRand [4] uses a wall of approximately one hundred lava lamps observed by a single camera, with related Cloudflare deployments using wave motion (Lisbon office) and hanging mobiles (Austin office). Each architecture is single-source or single-observation; multi-device deployment produces parallel instances of a single-source pattern rather than a multi-source generator in the SP 800-90B sense. A separate literature has developed parallel and multi-channel TRNG architectures in the optical / laser regime. Recent work has demonstrated massively parallel chaos based on chaotic microcombs [5], achieving an aggregation rate of 3.84 Tbps with inter-channel correlation below 0.04 across thirty-two channels. Two-dimensional chaotic laser arrays have achieved 4×4 independent channels with all cross-correlation coefficients below 0.05 [6]. The parallel-optical literature operates within a specific solution pattern: *independence is engineered into the optical substrate itself*, and the independence claim is supported by device-level cross-correlation measurements after the fact. This paper takes a step back from the question of *which apparatus to build* and asks a different question: *what should the architectural property of independence look like in a multi-source entropy generator*? The position developed here is that independence should be a *designed-for and measurable property of the joint observation*, not an assumed property of the substrate. The argument is framed at the architectural-principle level; specific apparatus, sensors, geometries, sampling configurations, and extraction algorithms are not proposed in this paper. The intent is to motivate a research direction, not to claim a particular instantiation. ## 2. Background and Related Work The prior art across thermal, optical, and parallel TRNG architectures can be organized along two axes: how many sources are sampled, and whether independence is assumed or measured. **Single-source thermal noise from electronic components.** Matsuoka 2021 [2] presents four PSoC TRNG variants, three of which use the internal resistors of a programmable gain amplifier as the noise source through a delta-sigma analog-to-digital converter. All four pass NIST SP 800-22 [10]. The architecture is single-source per device; the entropy density is bounded by the thermal noise variance of one resistor under one observation. Multi-device deployment produces multiple instances of the same architecture, not a multi-source entropy generator in the SP 800-90B sense. **Single-camera thermal-pixel noise from CMOS sensors.** Vault12's TrueEntropy [3] uses the thermal noise of CMOS image sensor pixels in a standard smartphone camera; the application has been evaluated under standard NIST randomness testing and is openly available as iOS source code. The architecture is single-camera; the entropy density is bounded by the variance of one CMOS sensor's pixel-noise distribution. **Single-camera optical-chaos observation.** Cloudflare's LavaRand [4] observes approximately one hundred lava lamps from a single camera and mixes the resulting pixel-stream with the production data center's local entropy. The framework's own technical disclosure notes that LavaRand is a secondary independent source — the primary is RDRAND — and that the camera-mixed entropy is one input among several. The architecture is single-camera; multi-deployment instances (Lisbon, Austin) use different physical phenomena under the same single-camera pattern. **Wearable sensor entropy extraction.** Recent work [7] has explored wearable-device sensors (heart rate variability, accelerometer/gyroscope, photoplethysmography, electrodermal activity, skin temperature) as entropy sources for cryptographic key generation. The architecture varies per device but operates within the single-wearable, single-physical-modality paradigm; multi-device deployment is parallel-single-source rather than multi-source-spatial. **Parallel optical/laser TRNG.** The optical chaos literature has developed parallel TRNG architectures using chaotic microcombs [5] (3.84 Tbps, inter-channel correlation < 0.04), chaotic laser arrays [6] (4×4 channels, cross-correlation < 0.05), and spatial-light-modulator + CMOS-camera spatiotemporal chaos. These architectures operate within a specific approach to independence: *the substrate is engineered so that channels are independent by construction*. Independence is then verified post-hoc through cross-correlation measurements at the device level. The pattern across the prior art is consistent. Single-source architectures rely on the variance of one physical observation; multi-source architectures in the optical regime rely on substrate-level engineered independence. **No published architecture, to the author's working knowledge of the field, treats independence as a measurable property of the joint multi-source observation itself rather than as a substrate property to be verified after the fact.** This is the architectural gap the present paper identifies as a research direction. ## 3. Independence as an Architectural Property The position developed here is that independence in a multi-source entropy generator should be designed for at the architectural layer — built into the system's design specification so that independence can be observed, measured, and audited at the joint-observation level. The argument has three components. [FIGURE_1] **Component A — Independence as a measurable architectural target.** NIST SP 800-90B requires that multi-source entropy generators combine sources only when the sources are independent. In current practice, this requirement is met by substrate engineering: the system is built such that, by physical construction, the sources are independent. Independence is then *checked* by cross-correlation measurement, but the architecture itself does not *enforce* independence; it assumes it. The architectural alternative is to design the system so that independence is the *property the joint extraction is engineered to verify and preserve*, rather than the property the substrate is engineered to provide. In this alternative architecture, the extraction layer's central task is independence verification, not noise mixing. **Component B — Independence at the joint-observation level, not the per-source level.** The current parallel-TRNG pattern verifies independence at the source level — channel X has cross-correlation below threshold C with channel Y. The architectural alternative proposed here is to verify independence at the *joint observation*: given a set of simultaneous observations from multiple sources, the extraction layer separates jointly-observable shared components from per-source residual components, retains the residuals whose joint distribution can be verified independent, and discards the rest. The shift is from *trusting that the substrate produces independence* to *measuring independence in the observation and conditioning the output to preserve only the verifiably independent portion*. **Component C — Conformance with NIST SP 800-90B as a design target, not a test pass.** NIST SP 800-90B specifies design principles, health tests, and conditioning functions for entropy sources. Architectures designed under the principle proposed here would treat the SP 800-90B health-test suite as an *architectural conformance target*: the health tests operate on the joint output as an integral part of the architecture, not as an external validation step after deployment. The independence-verifiable property is built into the system rather than tested for after the fact. The three components together describe an architectural class — multi-source entropy generators in which independence is a designed-for, measurable, and architecturally enforced property of the joint observation. The paper does not claim a specific apparatus in this class; the position is that the class itself is worth pursuing. **Mathematical framing.** In information-theoretic terms, the proposed architectural class targets a joint extraction *f*(*X*₁, …, *X*ₙ) → *Y* such that the pairwise mutual information *I*(*Y*ᵢ ; *Y*ⱼ) is bounded above by a configurable verification threshold for all retained output components *Y*ᵢ, *Y*ⱼ. The extraction is conditioned on the joint observation (*X*₁, …, *X*ₙ) so that shared components — components present in more than one source — can be estimated and conditioned away before the residual independently-supported components are retained. The independence claim becomes a measurable property of the retained output *Y* under the architecture's runtime, not an assumed property of the source substrate *X*. NIST SP 800-90B's health-test suite operates on *Y* as part of the architecture's continuous operation, not as a one-time certification event. The architectural class is parameterized by the verification threshold, the extraction function family, and the conformance target; specific instances of those parameters define specific architectures within the class. **Falsification criteria.** The position developed here is falsifiable on two axes. *(1)* If a multi-source entropy architecture built under the proposed class produces an independent-entropy output rate consistently lower than that of an otherwise-equivalent substrate-engineered architecture in the same physical regime, the operational value of the proposed class is contested. *(2)* If theoretical bounds on extractable independent entropy from a joint observation can be shown to be saturated by current substrate-engineered approaches — that is, if the joint-observation approach offers no measurable architectural benefit beyond what substrate engineering already achieves — the necessity of the proposed class is contested. The architectural class is therefore an empirical research target, not a theoretical claim that is immune to disproof. **Why the field has not already taken this direction.** A reasonable objection to the position above is that, if it were valuable, the field would already have moved this way. Three factors plausibly account for the current absence. *First*, in the optical/laser regime where parallel multi-channel TRNG architectures have been most actively developed, the engineered substrate (chaotic microcombs, multimode laser arrays) admits natural decorrelation through device physics; the operational pressure to design verification into the joint extraction has been low because the substrate produces near-independence by construction. *Second*, in the thermal-source regime, single-source architectures (resistor thermal noise, CMOS pixel noise) have been operationally adequate for many cryptographic-engineering applications, and the cost-benefit of moving to multi-source has not been articulated in the entropy-quality terms developed here. *Third*, the independence-verification layer described in §3, Component B requires statistical machinery (joint-distribution estimation, conditional independence testing under SP 800-90B health-test constraints) whose tooling has matured significantly in recent years but was not standard practice in earlier TRNG design epochs. None of these explain why the direction is closed; they explain why the direction has been open and unattended. ## 4. MILO as the Working Laboratory The architectural direction described in §3 — independence as a designed-for, measurable, architecturally enforced property — is being explored in practice on MILO (Modular Intelligent Learning Orchestrator), the patent-pending adaptive AI orchestration architecture developed by the author [8]. MILO is the working substrate for the architectural class proposed here. Three architectural properties of MILO map directly onto the requirements of the proposed class. *(i)* A sensor-receptor abstraction admits multiple physical-input sources observing a common phenomenon and emits their samples through an audit-first signal bus. *(ii)* The audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, ensuring that every entropy-capture event and every quality-metric report is auditable end-to-end. *(iii)* A monitoring subsystem publishes entropy-quality reports backed by persisted events, so the cryptographic consumer's post-hoc verification of *which capture events contributed to which seeds* is a mechanical property of the architecture rather than a logging convention. MILO is not the only orchestrator that could host the architectural class proposed in §3, but it is the substrate on which the author is developing the direction. The compatibility described above is therefore not hypothetical — it is the working hypothesis under which MILO has been submitted under the U.S. Department of Energy Genesis Mission [9]. ## 5. Implications and Discussion For *design*, the position implies that future multi-source entropy architectures should target measurable independence at the joint-observation level as a design specification rather than as a post-deployment validation step. The implication is not that current substrate-engineered approaches are unsafe; it is that an architectural class exists in which the independence claim becomes a property of the design rather than a property of the test report. For *evaluation*, the position implies that NIST SP 800-90B independence verification — operationally non-trivial in any multi-source architecture — could become an integral part of the architecture's runtime rather than a one-time validation event. The verification of independence becomes a continuous property of the joint output, not a snapshot taken at certification time. For *deployment*, the position implies that high-consequence cryptographic applications — including those in critical infrastructure protection, secure communication for industrial control systems, and entropy seeding for autonomous-system command-and-control — should evaluate the architectural class proposed here as a candidate research direction for their next-generation entropy supply. The DOE Genesis Mission's emphasis on advanced manufacturing, grid reliability, and human-in-the-loop AI in high-consequence domains [9] is a natural deployment context. ## 5.1 Limitations This paper does not present an apparatus, an empirical evaluation, or a worked instance of the proposed architectural class. The position is presented at the architectural-principle level only; specific apparatus, sensor configurations, geometries, sampling protocols, and extraction algorithms are not proposed. The compatibility argument with MILO's sensor-receptor subsystem [8] is illustrative, not load-bearing. Two specific empirical questions are unresolved: (i) whether joint-extraction architectures of the proposed class can produce independent-entropy throughput competitive with substrate-engineered parallel-optical TRNGs [5], [6] under comparable optical regimes; and (ii) whether the runtime independence-verification machinery imposes throughput penalties incompatible with cryptographic-seeding cadences in high-consequence deployments. Both are forthcoming work and bound the falsifiability criteria in §3. ## 6. Conclusion This paper has proposed an architectural research direction for multi-source cryptographic entropy generation: that independence should be a *designed-for, measurable, and architecturally enforced property* of the joint observation, rather than an assumed property of the substrate. The position is positioned within the NIST SP 800-90B framework for multi-source entropy generators [1] and is distinguished from the current pattern of substrate-engineered parallel chaos sources [5], [6], single-source thermal TRNGs [2], [3], single-camera optical-chaos sources [4], and wearable sensor entropy extraction [7]. The position is presented at the architectural-principle level only; specific apparatus, sensor configurations, geometries, sampling protocols, and extraction algorithms are not proposed in this paper. The architectural connection to MILO's sensor-receptor subsystem [8], submitted under the U.S. Department of Energy's Genesis Mission [9], illustrates compatibility at the public-architecture level. Related architectural directions — latency-aware authentication in industrial control, supervisory primacy for human-in-the-loop AI orchestration, structural principles for adaptive AI architecture, and the discipline of viability under non-stationary conditions — are developed in related work by the author. --- ## Data Availability All architectural materials, source manuscripts, the reference implementation, and accompanying figures are openly available at https://github.com/jmontano1/milo-architecture and permanently archived at Zenodo (DOI: [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025)). No private datasets are referenced; the architectural framework itself is the subject of this paper. Patent rights for the underlying MILO software architecture are reserved; the ~MILO trademark is held under USPTO Serial No. 99706004 (intent-to-use, Class 009). ## References [1] M. S. Turan, E. Barker, J. Kelsey, K. A. McKay, M. L. Baish, and M. Boyle, *Recommendation for the Entropy Sources Used for Random Bit Generation*, NIST SP 800-90B, National Institute of Standards and Technology, Jan. 2018. doi:10.6028/NIST.SP.800-90B [2] M. Matsuoka, "A true random number generator that utilizes thermal noise in a programmable system-on-chip (PSoC)," *International Journal of Circuit Theory and Applications*, vol. 49, no. 10, pp. 3354–3367, May 2021. doi:10.1002/cta.3046 [3] Vault12, *TrueEntropy: High Volume Thermal Entropy Generator for iOS*, [Online]. Available: https://github.com/vault12/TrueEntropy and https://apps.apple.com/us/app/trueentropy/id1299321174 [4] Cloudflare, Inc., "LavaRand in Production: The Nitty-Gritty Technical Details," *Cloudflare Blog*, 2017–2024. [Online]. Available: https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/ [5] B. Shen, H. Shu, W. Xie, et al., "Harnessing microcomb-based parallel chaos for random number generation and optical decision making," *Nature Communications*, vol. 14, art. 4590, 2023. doi:10.1038/s41467-023-40152-w [6] Q. Chen, X. Tang, M. Xu, F. Zhang, F. Zhang, Y. Guo, M. Pu, and X. Luo, "Spatiotemporal chaos based on a multimode laser for parallel physical random number generation," *Optics Letters*, vol. 51, no. 8, pp. 2284–2287, 2026. doi:10.1364/OL.589666 [7] M. Svarcmajer, M. Kohler, Z. Krpic, and I. Lukic, "Entropy Extraction from Wearable Sensors for Secure Cryptographic Key Generation in Blockchain and IoT Systems," *Sensors*, vol. 25, no. 17, art. 5298, 2025. doi:10.3390/s25175298 [8] J. E. Flores Montano, *MILO (Modular Intelligent Learning Orchestrator)*, JM Automated Solutions. Patent pending. Submitted under the U.S. Department of Energy Genesis Mission, 2026. [9] U.S. Department of Energy, "The Genesis Mission: Transforming Science and Energy with AI," Office of the Under Secretary for Science, Executive Order 14363, November 2025. [Online]. Available: https://www.energy.gov/genesis [10] L. E. Bassham et al., *A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications*, NIST SP 800-22 Rev. 1a, National Institute of Standards and Technology, Apr. 2010. doi:10.6028/NIST.SP.800-22r1a --- ## About the author Jorge Enrique Flores Montano (ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418); jmontano@jmautomated.com) is the founder of JM Automated Solutions and the inventor of MILO. A full biography is maintained at [https://www.milo-usa.com/jorge-enrique-flores-montano](https://www.milo-usa.com/jorge-enrique-flores-montano). ## Conflict of Interest and Funding Disclosure The author is the inventor of MILO (patent pending) and the founder of JM Automated Solutions. The architectural research direction proposed in this paper is a contribution from a working development program in which the author retains sole authorship and inventive interest. No external funding was received for the preparation of this manuscript. The author retains all rights to MILO and to the architectural framing articulated herein. ## Appendix A — About MILO MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture organized into discrete, single-responsibility subsystems under a strict separation-of-concerns discipline. An audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, producing an append-only audit trail that survives arbitrary process termination. The architecture is designed for *viability* — operational continuity under non-stationary conditions — rather than for prediction accuracy against an expected future. ### Eight structural principles Six are established physical, informational, control-theoretic, and statistical laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems. 1. **Second Law of Thermodynamics** — entropy treated as an architectural diagnostic signal, not a fault to be suppressed. 2. **Ashby's Law of Requisite Variety** — a regulator must possess variety at least equal to the system it regulates; implemented as a fleet of specialist agents matching the operational domain. 3. **Shannon Information Theory** — variance reduction occurs at the signal-carrier level, not redundantly at each consumer. 4. **Principle of Least Action — Single-Target Dispatch** — every command has one explicit target; no implicit resolvers, no opaque dispatchers. 5. **Lyapunov-Style Bounded Response** — every adaptive subsystem admits an explicit halt-and-resume pathway; adaptation that drifts unboundedly is failure, not learning. 6. **Power-Law Distribution Architecture** — engineered for the 99th-percentile event, not the median. 7. **Individual-Baseline Variance Modeling** *(original framework)* — operator-layer interventions calibrated against the individual's own established performance baseline, never a population norm. Design-stage; pending empirical validation. 8. **Precision Perturbation Without Variance Compression** *(original framework)* — operator-layer interventions shift probability mass toward high-reliability decision outputs while preserving operator authority and the variability that *is* the operator's adaptive intelligence. Design-stage; pending empirical validation. ### Eight operational integrity constraints Architectural commitments designed to be implemented as enforceable safeguards in deployment builds — not as runtime policy. Disabling any constraint should require rebuilding from source, not toggling a flag. 1. **No coercion, ever** — the system issues recommendations, never compels. 2. **Individual baseline only** — measurements against the operator's own baseline; never against a population norm or productivity target. 3. **No surveillance architecture** — performance-support tool, not a monitoring infrastructure. 4. **Operator authority is the invariant** — the system expands effective decision options; it never narrows or preempts them. 5. **Operational transparency** — every recommendation includes a plain-language explanation. 6. **Data sovereignty** — operator-layer data belongs to the institutional program under documented data governance. 7. **Override always available** — overrides are logged for audit but never used for adverse personnel action. 8. **Independent oversight** — operator-layer deployments require institutional ethics-board review, published consent frameworks, and periodic third-party audits. ### Unifying principle > *MILO does not predict the future. It remains viable in any future.* The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle. ### Trademark, patent, and submission status - **Mark.** *~MILO™* — U.S. Patent and Trademark Office Serial No. 99706004; filed March 16, 2026; intent-to-use; International Class 009 (downloadable AI software). The leading tilde disambiguates from senior MILO marks held by unrelated owners in different International Classes. - **Patent.** Patent application pending for the underlying software architecture. Implementation may require a patent license once issued; nothing in this document or its CC BY 4.0 license on the manuscript text grants any patent license. - **Federal submission.** Submitted to the U.S. Department of Energy under the *Genesis Mission* (Executive Order 14363, November 2025); currently under review. No acceptance or grant outcome is claimed. - **Concept DOI.** [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025) — Zenodo, persistent across versions. - **Public reference.** [https://github.com/jmontano1/milo-architecture](https://github.com/jmontano1/milo-architecture). - **Author contact.** Jorge Enrique Flores Montano · jmontano@jmautomated.com · ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418). # Article 02: Latency-Aware Authentication --- title: "Latency-Aware Authentication in Industrial Control Environments" subtitle: "Consequence-Graded Authorization Beyond the Web Latency Budget" author: "Jorge Enrique Flores Montano" author_aliases: ["Jorge Flores Montano", "Jorge Montano", "Jorge E. Flores Montano", "J. E. Flores Montano"] affiliation: "JM Automated Solutions" date: 2026-05-11 description: "Consequence-graded authentication as an architectural discipline for industrial control environments, composed orthogonally with ISA/IEC 62443 attacker-class Security Level tiers and operationalized through MILO's pre-execution gating module. Grounded in the author's industrial vision deployment experience across food, beverage, pharmaceutical, and medical-device manufacturing domains." keywords: - MILO - Modular Intelligent Learning Orchestrator - Jorge Flores Montano - Jorge Montano - Jorge Enrique Flores Montano - JM Automated Solutions - industrial control authentication - latency-aware authentication - operational technology security - OT cybersecurity - ISA/IEC 62443 - NIST SP 800-82r3 - NIST SP 800-207 - Zero Trust OT - pre-execution gating - consequence-graded authorization - CISA Critical Manufacturing Sector - DOE Genesis Mission - patent pending - adaptive AI architecture - critical infrastructure - U.S. national interest tags: - milo - industrial-control - ot-cybersecurity - isa-iec-62443 - nist-sp-800-82r3 - zero-trust - jorge-flores-montano - jm-automated-solutions - doe-genesis-mission - adaptive-ai - patent-pending - critical-infrastructure - latency-aware-authentication article_number: 2 series_name: "MILO Architectural Series" series_total: 5 canonical_url: "https://www.milo-usa.com/articles/02-latency-aware-authentication" trademark: "~MILO™ is a trademark of Jorge Enrique Flores Montano (USPTO Serial No. 99706004)" patent_status: "Patent Pending" copyright: "© 2026 Jorge Enrique Flores Montano / JM Automated Solutions" --- # Latency-Aware Authentication in Industrial Control Environments **Subtitle:** Consequence-Graded Authorization Beyond the Web Latency Budget **Author:** Jorge Enrique Flores Montano · Founder, JM Automated Solutions **~MILO™** — Modular Intelligent Learning Orchestrator (patent pending) **Publication date:** May 2026 --- ## Abstract Authentication patterns developed for web and cloud environments — OAuth round-trips, TLS handshakes, multi-factor authentication challenges — often assume tens to hundreds of milliseconds of permissible latency per authorization event. Industrial control environments operate on fundamentally tighter budgets. Machine vision inspection loops can run on single-millisecond timescales; programmable logic controller (PLC) scan cycles are measured in milliseconds; real-time motion-control decisions may admit no perceptible authentication overhead at all. The result is a recurring industrial-control gap: authentication is either applied at the perimeter and absent inside the control loop, or it is grafted on with timing penalties that operators and integrators are incentivized to bypass. This paper proposes *latency-aware authentication* as an adaptive design discipline for industrial control environments: authentication strength is graded against operational consequence per control cycle rather than applied uniformly. The discipline complements the attacker-class security level tiers (SL1–SL4) of ISA/IEC 62443 [1] with an orthogonal consequence-class axis, and operates within the operational technology security framing of NIST SP 800-82r3 [2]. The paper is grounded in the author's hands-on industrial vision deployment experience across food, beverage, pharmaceutical, and medical-device manufacturing domains, and illustrated using MILO, a patent-pending adaptive AI orchestrator [3] whose pre-execution gating subsystem implements the discipline in software. **Keywords:** industrial control, operational technology, latency-aware authentication, ISA/IEC 62443, NIST SP 800-82, adaptive authentication, pre-execution gating. **Highlights.** - Proposes *latency-aware authentication* as an adaptive design discipline for industrial control: authentication strength graded against operational consequence per control cycle rather than uniformly. - Composes orthogonally with the attacker-class Security Level tiers (SL1–SL4) of ISA/IEC 62443, introducing a consequence-class axis aligned with NIST SP 800-82r3's operational technology framing. - Specifies five architectural commitments — including pre-execution gating with three outputs (allow / hold-block / recommend) and persist-before-deliver audit across all consequence tiers. - Grounded in seven years of industrial-vision deployment experience across food, beverage, pharmaceutical, and medical-device manufacturing. **Index Terms:** industrial control, operational technology security, latency-aware authentication, ISA/IEC 62443, NIST SP 800-82, NIST SP 800-207, adaptive authentication, pre-execution gating, Zero Trust architecture, critical manufacturing. **Plain Language Summary.** Authentication methods designed for the web — typing a password, getting a text-message code, completing an OAuth handshake — assume the user has hundreds of milliseconds to a few seconds to respond. Industrial control systems running manufacturing lines, power grids, and chemical plants do not have that budget; their decisions happen in milliseconds. As a result, authentication is often pushed to the perimeter and then absent inside the control loop, or grafted on with timing penalties that operators are pressured to bypass. This paper proposes grading the strength of authentication against the operational consequence of each individual control command, so that high-consequence actions get deliberate human authorization while routine actions pass through a lightweight log. The approach composes with existing industrial cybersecurity standards rather than replacing them. **Relevance to U.S. National Interest.** Critical-manufacturing cybersecurity is a designated U.S. national-interest sector under CISA's Critical Manufacturing Sector framework. Industrial control authentication is identified by NIST SP 800-82r3 as a gap requiring sector-specific guidance. The discipline proposed here addresses that gap directly and is aligned with the DOE Genesis Mission's advanced-manufacturing and grid-reliability priorities. **Status of claims.** The framework proposed here — *latency-aware authentication graded by operational consequence*, composed orthogonally with the attacker-class Security Level tiers of ISA/IEC 62443 [1] — is the author's original architectural discipline; the composition is described as a proposal, not as an existing certification. The latency budgets in §3 are illustrative ranges drawn from generic industry references; specific deployments vary by application. The compatibility argument with NIST SP 800-82r3 [2], NIST SP 800-207 [6], and NIST AI 100-1 [11] reflects the author's reading of those documents and is design intent, not a compliance attestation. The author's industrial-vision deployment context grounds the framework in operational reality but does not constitute external validation; empirical evaluation against an instrumented industrial-control deployment is forthcoming work. This manuscript is a preprint prior to peer review. **About MILO.** MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture for high-consequence critical-infrastructure environments. The full architectural reference — eight structural principles, eight operational integrity constraints, the unifying viability principle, and the trademark/patent status — is maintained as a single canonical document at https://github.com/jmontano1/milo-architecture (concept DOI: 10.5281/zenodo.20117025). Author contact: jmontano@jmautomated.com. --- ## 1. Introduction The latency budget of the modern industrial control loop is set by physics, not by security policy. A high-speed machine vision system inspecting items on a conveyor at sixty items per second admits roughly sixteen milliseconds per item, of which the camera exposure, image acquisition, classification, and reject-arm signal must all complete inside the deterministic budget. A PLC executing a safety-relevant logical operation typically operates on a scan cycle of one to ten milliseconds; a missed scan is a deviation event that may trigger a corrective action program entry. A robotic motion controller maintaining position accuracy at the micrometer scale runs control loops at one kilohertz or higher, with each loop admitting no more than tens of microseconds of computation. Authentication patterns from the web stack — designed for human-perceptible interactions with response budgets between one hundred milliseconds and two seconds — cannot be inserted into these loops without violating the operational physics. The standard industry response has been to push authentication to the perimeter. Operators authenticate at the human-machine interface (HMI), the perimeter accepts or rejects the operator, and authenticated sessions then issue uncredentialed control commands inside the control loop. The pattern works while the perimeter is intact and the session is trusted. It does not work when the perimeter is breached, when sessions are hijacked, when the operator's credential set has changed during the session lifetime, or when the operational consequence of a single control command warrants finer-grained authorization than session-level trust provides. Recent operational technology cybersecurity incidents — including high-profile ransomware events in critical infrastructure — have made plain that session-level perimeter authentication is insufficient for high-consequence control loops. The standard alternative — grafting full authentication onto each control command — fails on the other axis. The latency penalty of a per-command OAuth round trip or multi-factor challenge can exceed the operational budget by one to three orders of magnitude. The overhead is then likely to be bypassed, moved out of the loop, or disabled during commissioning; the security control becomes vestigial. The present paper proposes a third path. *Latency-aware authentication* grades authentication strength against the operational consequence of the specific control cycle, rather than applying a uniform authentication level across all commands or applying authentication only at session establishment. A motion-control command that maintains tracking under normal operation passes through a lightweight pre-execution gate. A motion-control command that crosses a safety-relevant threshold — exceeding a force limit, leaving a confined operational envelope, or commanding a state transition with downstream production consequence — passes through a heavier gate that admits the human operator's authorization with the latency budget of human decision-making, deliberately. The discipline is not "fast authentication" or "slow authentication"; it is *authentication graded by consequence*. ## 2. Background and Related Work **Operational technology security standards.** NIST SP 800-82r3 [2], published in September 2023, is the canonical guide to operational technology (OT) security. It specifies that OT systems differ from conventional IT systems in their prioritization of availability, integrity, and safety, and that security controls for OT must accommodate the deterministic real-time requirements of industrial control. The document does not provide a specific framework for latency-aware authentication; the gap addressed by the present paper is identified by NIST SP 800-82r3 as an active area requiring sector-specific guidance. **ISA/IEC 62443 Security Levels.** The ISA/IEC 62443 series [1] provides the international framework for industrial cybersecurity, structured around four Security Levels (SL1 through SL4) ranging from protection against unintentional or accidental misuse (SL1) to protection against intentional misuse using sophisticated means with extensive resources and motivation (SL4). The Security Levels are *attacker-class tiers*: they grade the security control by the capability of the adversary the control is designed to resist. The present paper's contribution is an *orthogonal consequence-class axis*: graded by the operational consequence of the protected command rather than the capability of the adversary. The two axes compose: a command at SL3 attacker-class with high operational consequence requires both strong cryptographic credentials and a deliberate human authorization gate; a command at SL3 attacker-class with low operational consequence requires the cryptographic credentials and a lightweight pre-execution log. The composition is the contribution. **Adaptive and risk-based authentication.** The adaptive-authentication literature [4], [5] develops the principle of grading authentication challenge against contextual risk factors — device, geolocation, time, behavioral biometrics. The literature has primarily addressed the consumer cloud and enterprise IT context, where contextual factors are abundant and the latency budget is human-perceptible. The framework of Adaptive Context-Aware Security (ACASF) [5] is a representative recent example. The present paper extends the principle to industrial control by substituting *operational consequence per control cycle* for *user context* as the grading axis, and by operating within latency budgets that the IT-context literature does not address. **Zero Trust architecture in OT.** Zero Trust architecture, as formalized by NIST SP 800-207 [6], requires continuous evaluation of access rather than perimeter-only trust. Applying that principle in OT is difficult because control-loop latency budgets are materially different from enterprise IT latency budgets. The present paper is consistent with Zero Trust framing: the consequence-graded pre-execution gate is the mechanism by which continuous verification becomes operationally compatible with the OT latency budget. ## 3. Operational Latency Budgets in Industrial Domains The discipline of latency-aware authentication is grounded in the actual latency budgets observed in industrial deployment. The figures here are illustrative and drawn from generic industry references; specific deployments vary by application. | Industrial Domain | Typical Latency Budget | Authentication Compatibility | |---|---|---| | Motion control (servo loops) | 100 µs – 1 ms per loop | No authentication compatible per loop; session-level only with structural override | | PLC scan cycle (logic execution) | 1 – 10 ms per scan | Lightweight pre-execution log compatible; cryptographic handshake incompatible | | Machine vision inspection (high-speed line) | 5 – 50 ms per item | Lightweight gate compatible; full MFA incompatible | | HMI operator interaction | 100 – 2000 ms per action | Full MFA / human-perceptible challenge compatible | | Supervisory control / SCADA reconfiguration | 1 – 10 s per action | Deliberate authorization gate compatible; full MFA with audit trail | | Production schedule / recipe change | 10 s – 60 s per action | Multi-party authorization gate compatible; institutional review | The table is not exhaustive; it illustrates the principle that the operational latency budget varies across at least five orders of magnitude in a single industrial system. A uniform authentication strategy that does not accommodate this variation either over-protects fast loops to operational impossibility or under-protects slow operations to security insufficiency. ## 4. Latency-Aware Authentication as an Architectural Discipline The discipline of latency-aware authentication is operationalized through five architectural commitments. [FIGURE_1] **C1 — Consequence classification before authentication design.** Every action class in the industrial control system is assigned an operational-consequence tier prior to authentication design. The tier captures the maximum downstream consequence of a single instance of the action, not the typical case. A motion-control loop's typical command has low consequence (incremental position adjustment); the same loop's threshold-crossing command (force-limit exceedance, envelope departure) has high consequence. The classification is the substrate; the authentication design follows. **C2 — Pre-execution gating with three outputs.** Every action passes through a pre-execution gate with three permitted outputs: *allow* (logged), *hold/block* (with plain-language operational explanation), or *recommend* (safer alternative) [7]. The gate's latency budget is set by the operational consequence tier: low-consequence actions pass through a sub-millisecond log-only gate; high-consequence actions pass through a deliberate authorization gate calibrated to human decision-making latency. The architectural pattern is the same across tiers; the latency budget and the authorization requirement vary. **C3 — Persist-before-deliver across all tiers.** Every gated action persists to the audit log before it dispatches, including low-consequence actions whose gate is log-only [3]. The pattern, named *persist-before-deliver*, ensures that the audit trail is intact across the full operational lifecycle of the system, not only at the gates where human authorization was required. Post-hoc reconstruction of an incident does not depend on which tier the gated action occupied; every action's audit record is recoverable. **C4 — Operator authority preserved across all tiers.** The operator's authority to override the gate's recommendation, or to invoke a halt command independent of the gate, is preserved at every tier [4]. The override is logged for audit but never used to trigger adverse personnel or operational consequences. The architectural commitment, named *operator authority is the invariant*, ensures that latency-aware authentication does not become a mechanism by which the operator's authority is gradually preempted as the system's autonomy increases. **C5 — Tier composition with ISA/IEC 62443 SLs.** The consequence-class tier composes with the attacker-class Security Level. A command's full authorization profile is the Cartesian product of (SL, consequence tier). The pattern admits the configuration in which a system whose attacker-class is SL2 (intentional misuse with simple means) protects its high-consequence actions with the same deliberate authorization gate as an SL4 system, while leaving its low-consequence actions at lightweight protection appropriate to the threat profile. **C6 — Dynamic consequence reclassification under fault conditions.** Consequence classification is not static. A command that is routine under nominal operating conditions may carry elevated consequence under a developing fault — a motion-control position adjustment that is incremental at normal load may be safety-relevant when force limits are approaching threshold, or when a downstream interlock has degraded. The discipline therefore requires that consequence classification operate as a state-machine input to the pre-execution gate rather than as a static command attribute. Architecturally, the gate evaluates *(command, current operational state)* rather than *(command)* alone. The architectural consequence is that the gate's tier assignment is itself a runtime decision; the design challenge is to keep the tier-evaluation latency within the operational budget while admitting the reclassification logic the safety profile requires. **Formal sketch of the pre-execution gate.** The gate is a function *G*: (*C*, *S*) → *O* × *L*, where *C* is the candidate command, *S* is the current operational state (including the attacker-class Security Level under ISA/IEC 62443, the consequence-class tier under C1, the operator-authority context (the architectural principle that the human-authoritative state is the default for consequential actions, consistent with EU AI Act Article 14 [12] and the Parasuraman–Sheridan–Wickens levels-of-automation framework [13]), and the fault-state reclassification under C6), *O* is one of three outputs *{allow, hold/block, recommend}*, and *L* is the latency budget for the assigned tier (sub-millisecond for lightweight log; deliberate-human latency for high-consequence authorization). Every gate evaluation persists to the audit log before any downstream action — the *persist-before-deliver* discipline that makes the gate's behavior reconstructable post-hoc. The gate is single-shot per command and stateless beyond the input *S*; state-machine dynamics produce updates to *S* that subsequent gate evaluations see. The gate is therefore not a security policy engine in the conventional Policy-Decision-Point sense; it is a per-command consequence-graded authorization checkpoint with explicit operator-override semantics built in. **Zero Trust integration.** NIST SP 800-207 [6] specifies the Zero Trust principles of continuous verification, assume breach, and least privilege. The discipline proposed here is consistent with all three: continuous verification is operationalized by *S* being a live state input to every gate evaluation rather than a session-establishment artifact; assume breach is addressed by the per-command authorization gate rather than perimeter trust; least privilege is enforced at the consequence-class tier rather than uniformly. The contribution of the discipline relative to NIST SP 800-207 is the explicit operational-consequence axis: existing Zero Trust frameworks grade trust against user context (device, location, behavior); the discipline here grades the gate's required authorization strength against the consequence of the protected control action. ## 5. Operationalization in MILO The discipline is operationalized in MILO through the Guardrail and Validation module of the v.4 architecture [7]. The module implements pre-execution gating with the three outputs (allow, hold/block, recommend), routes each gated action through the audit-first command bus [3], and preserves operator override authority at every gate. The module's tier configuration admits the consequence-class tier as a per-action parameter; the latency profile of the gate varies with the tier. Explicit-target dispatch — every command has one explicit target, dispatched through the audit-first command bus with no implicit resolver [3] — is the substrate that makes Commitment C3 (persist-before-deliver across all tiers) operationally enforceable. A command whose target is implicit or whose dispatch is auto-chained from a prior command's completion cannot be reliably audited; MILO's architecture explicitly rejects auto-chaining and requires explicit commanding for every consequential action [8]. *Explicit commanding as a safety interlock* [8] is the discipline's specific safeguard against the auto-chain failure mode. The module is operationalized in MILO's machine-orchestration layer (v.4) [3]. The extension to the operator-cognitive performance layer (v.5) — Cognitive-State-Aware Decision Support, Operator-Task Alignment Under Load, and the Sustained Operational Capacity layer — applies the same gating discipline to actions whose authorization is mediated by operator cognitive state under the eight non-negotiable operational integrity constraints [9]. The v.5 extension is design-stage in the current MILO codebase and is presented in the framework's DOE Genesis Mission submission [9] under active development. ## 6. Author Authority and Industrial Context The discipline articulated in this paper is grounded in the author's hands-on deployment experience in industrial vision systems across regulated manufacturing domains, including food and beverage, pharmaceutical, and medical-device production. The author has not published the specific systems involved (industrial deployment specifications are typically protected by customer confidentiality), but the operational pattern observed across the domains is consistent: a uniform authentication strategy that does not grade against consequence fails in one of the two ways named in Section 1 — either by violating the operational latency budget or by being bypassed or moved out of the loop when the operational impact becomes evident. The discipline of consequence-graded pre-execution gating is the author's response, developed during deployment work and articulated here for the first time in publication form. ## 7. Implications and Discussion For *design*, the discipline implies that authentication strategies for industrial control systems must be designed before the operational consequence classification is known to be incomplete, and revisited as the classification is refined. The cost of a uniform strategy is paid at deployment, where operators discover the strategy's incompatibility with the operational budget; the cost of a consequence-graded strategy is paid up front in classification work and architectural design. The trade-off favors the up-front cost. For *evaluation*, the discipline implies that authentication strategies should be evaluated on per-tier metrics rather than aggregate measures. A strategy that protects high-consequence actions adequately while imposing operational friction on low-consequence actions is observationally indistinguishable from a strategy that under-protects high-consequence actions while leaving low-consequence actions unprotected — both produce similar aggregate authentication-attempt counts. The per-tier metrics (gate latency, override frequency, hold/block-to-allow ratio per tier) admit the distinction. For *deployment*, the discipline implies that industrial cybersecurity standards convergence around consequence-grading is operationally necessary, and that the ISA/IEC 62443 SL framework [1] composes naturally with a consequence-class axis without requiring revision of the SL definitions. The deployment context — DOE Genesis Mission emphasis on advanced manufacturing, grid reliability, and human-in-the-loop industrial systems [10] — is precisely the context in which consequence-graded authentication, rather than uniform authentication, is operationally appropriate. ## 7.1 Limitations The framework is presented at the architectural-discipline level; no instrumented industrial-control deployment results are reported in this manuscript. Three specific limitations bound the present contribution: (i) the consequence-class taxonomy (§4.C1) is specified as a deployment-time activity but no canonical taxonomy is offered, and inter-deployment portability of consequence classifications is an open question; (ii) the formal sketch of the pre-execution gate (§4) does not include a worst-case latency analysis under the kinds of state-machine pathologies that real industrial systems exhibit (sensor dropouts, transient PLC scan-overruns, network jitter); (iii) the composition argument with ISA/IEC 62443 SL tiers [1] reflects design intent rather than a certification outcome, and conformance to the standard's Common Requirement clauses is a deployment-level audit, not asserted by this manuscript. The author's industrial-vision deployment experience informs the framework but does not constitute external validation; empirical evaluation against an instrumented industrial-control deployment is forthcoming work. ## 8. Conclusion This paper has proposed *latency-aware authentication* as an architectural discipline for industrial control environments — authentication strength graded against operational consequence per control cycle, composed orthogonally with the ISA/IEC 62443 attacker-class Security Level framework [1], grounded in the latency budgets of real industrial domains, and operationalized through the pre-execution gating module of MILO [3], [7]. The discipline addresses a recurring industrial-control gap: web-derived authentication patterns can be operationally incompatible with control-loop latency budgets, and the standard responses (perimeter-only authentication, full per-command authentication with bypass-prone overhead) either under-protect or over-burden the system. The discipline is grounded in the author's industrial vision deployment experience and is consistent with NIST SP 800-82r3 [2], NIST AI 100-1 Appendix C [11], and Zero Trust architecture principles [6]. Related architectural directions — supervisory primacy for human-in-the-loop AI orchestration, structural principles for adaptive AI architecture, the discipline of viability under non-stationary conditions, and multi-source cryptographic entropy sourcing — are developed in related work by the author and share the same audit-first command bus substrate and operational integrity constraints. --- ## Data Availability All architectural materials, source manuscripts, the reference implementation, and accompanying figures are openly available at https://github.com/jmontano1/milo-architecture and permanently archived at Zenodo (DOI: [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025)). No private datasets are referenced; the architectural framework itself is the subject of this paper. Patent rights for the underlying MILO software architecture are reserved; the ~MILO trademark is held under USPTO Serial No. 99706004 (intent-to-use, Class 009). ## References [1] International Society of Automation / International Electrotechnical Commission, *ISA/IEC 62443 series — Industrial communication networks — Network and system security*. Geneva, Switzerland: IEC, 2009–2024. [2] National Institute of Standards and Technology, *Guide to Operational Technology (OT) Security*, NIST SP 800-82r3, Sep. 2023. doi:10.6028/NIST.SP.800-82r3 [3] J. E. Flores Montano, *MILO (Modular Intelligent Learning Orchestrator)*, JM Automated Solutions. Patent pending. Submitted under the U.S. Department of Energy Genesis Mission, 2026. [4] *Adaptive Authentication: Risk-Based Verification for Modern Enterprises*, Entrust Identity Platform Technical Brief, 2024. [5] M. Alqahtani et al., "Adaptive Context-Aware Security Framework for Zero Trust Architectures," *Preprints*, doi:10.20944/preprints202404, 2024. [6] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, *Zero Trust Architecture*, NIST SP 800-207, National Institute of Standards and Technology, Aug. 2020. doi:10.6028/NIST.SP.800-207 [7] J. E. Flores Montano, MILO v.4 — Guardrail and Validation module specification, internal architecture, in [3]. [8] *Explicit commanding is the safety interlock* — MILO architectural pattern, in [3]. [9] J. E. Flores Montano, MILO v.5 — Eight Operational Integrity Constraints (no coercion, individual baseline only, no surveillance, operator authority invariant, operational transparency, data sovereignty, override always available, independent oversight), in [3]. [10] U.S. Department of Energy, "The Genesis Mission: Transforming Science and Energy with AI," Office of the Under Secretary for Science, Executive Order 14363, November 2025. [Online]. Available: https://www.energy.gov/genesis [11] E. Tabassi, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1, National Institute of Standards and Technology, Jan. 2023, Appendix C. doi:10.6028/NIST.AI.100-1 [12] European Union, *Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)*, Article 14 (Human Oversight), Aug. 2024. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [13] R. Parasuraman, T. B. Sheridan, and C. D. Wickens, "A model for types and levels of human interaction with automation," *IEEE Transactions on Systems, Man, and Cybernetics — Part A: Systems and Humans*, vol. 30, no. 3, pp. 286–297, May 2000. doi:10.1109/3468.844354 --- ## About the author Jorge Enrique Flores Montano (ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418); jmontano@jmautomated.com) is the founder of JM Automated Solutions and the inventor of MILO. A full biography is maintained at [https://www.milo-usa.com/jorge-enrique-flores-montano](https://www.milo-usa.com/jorge-enrique-flores-montano). ## Conflict of Interest and Funding Disclosure The author is the inventor of MILO (patent pending) and the founder of JM Automated Solutions. The discipline proposed in this paper is a contribution from a working development program in which the author retains sole authorship and inventive interest. No external funding was received for the preparation of this manuscript. The author retains all rights to MILO and to the discipline articulated herein. ## Appendix A — About MILO MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture organized into discrete, single-responsibility subsystems under a strict separation-of-concerns discipline. An audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, producing an append-only audit trail that survives arbitrary process termination. The architecture is designed for *viability* — operational continuity under non-stationary conditions — rather than for prediction accuracy against an expected future. ### Eight structural principles Six are established physical, informational, control-theoretic, and statistical laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems. 1. **Second Law of Thermodynamics** — entropy treated as an architectural diagnostic signal, not a fault to be suppressed. 2. **Ashby's Law of Requisite Variety** — a regulator must possess variety at least equal to the system it regulates; implemented as a fleet of specialist agents matching the operational domain. 3. **Shannon Information Theory** — variance reduction occurs at the signal-carrier level, not redundantly at each consumer. 4. **Principle of Least Action — Single-Target Dispatch** — every command has one explicit target; no implicit resolvers, no opaque dispatchers. 5. **Lyapunov-Style Bounded Response** — every adaptive subsystem admits an explicit halt-and-resume pathway; adaptation that drifts unboundedly is failure, not learning. 6. **Power-Law Distribution Architecture** — engineered for the 99th-percentile event, not the median. 7. **Individual-Baseline Variance Modeling** *(original framework)* — operator-layer interventions calibrated against the individual's own established performance baseline, never a population norm. Design-stage; pending empirical validation. 8. **Precision Perturbation Without Variance Compression** *(original framework)* — operator-layer interventions shift probability mass toward high-reliability decision outputs while preserving operator authority and the variability that *is* the operator's adaptive intelligence. Design-stage; pending empirical validation. ### Eight operational integrity constraints Architectural commitments designed to be implemented as enforceable safeguards in deployment builds — not as runtime policy. Disabling any constraint should require rebuilding from source, not toggling a flag. 1. **No coercion, ever** — the system issues recommendations, never compels. 2. **Individual baseline only** — measurements against the operator's own baseline; never against a population norm or productivity target. 3. **No surveillance architecture** — performance-support tool, not a monitoring infrastructure. 4. **Operator authority is the invariant** — the system expands effective decision options; it never narrows or preempts them. 5. **Operational transparency** — every recommendation includes a plain-language explanation. 6. **Data sovereignty** — operator-layer data belongs to the institutional program under documented data governance. 7. **Override always available** — overrides are logged for audit but never used for adverse personnel action. 8. **Independent oversight** — operator-layer deployments require institutional ethics-board review, published consent frameworks, and periodic third-party audits. ### Unifying principle > *MILO does not predict the future. It remains viable in any future.* The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle. ### Trademark, patent, and submission status - **Mark.** *~MILO™* — U.S. Patent and Trademark Office Serial No. 99706004; filed March 16, 2026; intent-to-use; International Class 009 (downloadable AI software). The leading tilde disambiguates from senior MILO marks held by unrelated owners in different International Classes. - **Patent.** Patent application pending for the underlying software architecture. Implementation may require a patent license once issued; nothing in this document or its CC BY 4.0 license on the manuscript text grants any patent license. - **Federal submission.** Submitted to the U.S. Department of Energy under the *Genesis Mission* (Executive Order 14363, November 2025); currently under review. No acceptance or grant outcome is claimed. - **Concept DOI.** [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025) — Zenodo, persistent across versions. - **Public reference.** [https://github.com/jmontano1/milo-architecture](https://github.com/jmontano1/milo-architecture). - **Author contact.** Jorge Enrique Flores Montano · jmontano@jmautomated.com · ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418). # Article 03: Supervisory Primacy --- title: "Supervisory Primacy: Human-in-the-Loop AI Orchestration for High-Consequence Domains" subtitle: "The Architectural Form of Human Authority in Adaptive AI Systems" author: "Jorge Enrique Flores Montano" author_aliases: ["Jorge Flores Montano", "Jorge Montano", "Jorge E. Flores Montano", "J. E. Flores Montano"] affiliation: "JM Automated Solutions" date: 2026-05-11 description: "Supervisory Primacy as the architectural design principle by which human authority over consequential AI decisions becomes a constitutional property of an adaptive AI orchestration system rather than a runtime configuration. Consistent with EU AI Act Article 14, Parasuraman-Sheridan-Wickens supervisory control, and NIST AI RMF 1.0 Appendix C." keywords: - MILO - Modular Intelligent Learning Orchestrator - Jorge Flores Montano - Jorge Montano - Jorge Enrique Flores Montano - JM Automated Solutions - human-in-the-loop AI - HITL - Supervisory Primacy - AI oversight - human-AI interaction - EU AI Act Article 14 - NIST AI RMF - Parasuraman-Sheridan-Wickens - levels of automation - operator authority - adaptive AI architecture - DOE Genesis Mission - patent pending - critical infrastructure - U.S. national interest tags: - milo - human-in-the-loop - supervisory-primacy - ai-oversight - eu-ai-act - nist-ai-rmf - jorge-flores-montano - jm-automated-solutions - doe-genesis-mission - adaptive-ai - patent-pending - critical-infrastructure - operator-authority article_number: 3 series_name: "MILO Architectural Series" series_total: 5 canonical_url: "https://www.milo-usa.com/articles/03-supervisory-primacy" trademark: "~MILO™ is a trademark of Jorge Enrique Flores Montano (USPTO Serial No. 99706004)" patent_status: "Patent Pending" copyright: "© 2026 Jorge Enrique Flores Montano / JM Automated Solutions" --- # Supervisory Primacy: Human-in-the-Loop AI Orchestration for High-Consequence Domains **Subtitle:** The Architectural Form of Human Authority in Adaptive AI Systems **Author:** Jorge Enrique Flores Montano · Founder, JM Automated Solutions **~MILO™** — Modular Intelligent Learning Orchestrator (patent pending) **Publication date:** May 2026 --- ## Abstract Human-in-the-loop (HITL) frameworks for AI systems are increasingly treated as policy-level commitments — "the human can always override" — when their operational effectiveness requires that they be architectural properties of the system itself. A policy-level HITL commitment is disabled by a configuration flag; an architectural HITL property is disabled by rebuilding from source. This paper introduces *Supervisory Primacy* as a design principle: the human-authoritative state is the architectural default for consequential actions in adaptive AI orchestration systems, with the AI proposing and the human disposing, every consequential action carrying a mandatory authorization audit trail, and the eight non-negotiable operational integrity constraints implemented as enforceable safeguards in deployment builds rather than as runtime policy. Supervisory Primacy is consistent with the human oversight requirements of EU AI Act Article 14 [1], operates within the levels-of-automation taxonomy of Parasuraman, Sheridan, and Wickens [2], and is illustrated using MILO, a patent-pending adaptive AI orchestrator [3] submitted to the U.S. Department of Energy under the Genesis Mission [4]. The contribution is at the architectural level: Supervisory Primacy is not a new HITL taxonomy; it is the structural design that makes HITL load-bearing rather than retrofittable. **Keywords:** human-in-the-loop, AI oversight, supervisory control, EU AI Act, levels of automation, adaptive AI architecture, high-consequence systems. **Highlights.** - Introduces *Supervisory Primacy* as the architectural design principle by which human authority over consequential AI decisions becomes a constitutional property of the orchestration system, not a runtime configuration. - Operationalizes the principle through four architectural mechanisms: audit-first command-and-signal substrate, reflex predicates before fanout, pre-execution gating, and voluntary side-effect pathways. - Composes with EU AI Act Article 14, NIST AI RMF 1.0 Appendix C, the Parasuraman–Sheridan–Wickens framework, and the industrial-robotics functional-safety standards (ANSI/RIA R15.06, ISO 10218, ISO/TS 15066, IEC 61508/61511). - Specifies a threat model for the audit substrate requiring cryptographic chain-of-custody, custodial separation, and external WORM replication for high-consequence deployment posture. **Index Terms:** human-in-the-loop AI, supervisory control, AI oversight, EU AI Act, levels of automation, audit-first architecture, industrial robotics safety, functional safety, IEC 61508, ANSI/RIA R15.06, NIST AI RMF. **Plain Language Summary.** When an AI system operates in a setting where mistakes have severe consequences — a power grid control room, a nuclear facility, an operating room, an autonomous robotic line — the rule that "a human can always override the AI" must be more than a promise. It must be built into the architecture, so that disabling the override would require rebuilding the system from source, not toggling a setting. This paper names that architectural property *Supervisory Primacy*: the human-authoritative state is the default for any consequential action; the AI proposes and the human disposes; every consequential action carries a mandatory audit trail by architecture, not by policy. The principle does not invent human oversight; it specifies the structural form that makes existing human-oversight regulations operationally effective. **Relevance to U.S. National Interest.** Human oversight of AI in critical-infrastructure environments — energy grid operations, nuclear facility control, autonomous robotics under human-robot interface, satellite and space operations, first-responder coordination — is a foundational concern for U.S. critical-infrastructure protection. The principle articulated here provides the architectural substrate by which sector-specific oversight requirements (FDA, NHTSA, EASA, NRC, DOE) become operationally enforceable rather than promissory. **Status of claims.** *Supervisory Primacy* as articulated in this paper is the author's original architectural design principle. The EU AI Act Article 14 [1], the Parasuraman–Sheridan–Wickens framework [2], NIST AI RMF 1.0 [9], and the industrial-robotics functional-safety standards (R15.06 [11], ISO 10218 [12], ISO/TS 15066 [13], IEC 61508/61511 [14]) are external references with established standing in their respective regulatory and engineering communities; this paper reads them and proposes an architectural substrate that composes with them. Conformance with any specific standard is a deployment-level assessment, not a certification claim. The audit-substrate hardening commitments specified in §4 are architectural requirements proposed for high-consequence deployment posture; specific implementations and validation against actual incident-reconstruction scenarios are forthcoming work. This manuscript is a preprint prior to peer review. **About MILO.** MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture for high-consequence critical-infrastructure environments. The full architectural reference — eight structural principles, eight operational integrity constraints, the unifying viability principle, and the trademark/patent status — is maintained as a single canonical document at https://github.com/jmontano1/milo-architecture (concept DOI: 10.5281/zenodo.20117025). Author contact: jmontano@jmautomated.com. --- ## 1. Introduction The fully autonomous AI orchestration system is structurally unsafe for industrial control, medical decision support, energy grid operations, and other high-consequence domains — not because the AI is unreliable in any individual decision, but because the escalation pathway and the traceability of decision authority cannot be reconstructed forensically when the system is fully autonomous. Every incident review of a sociotechnical failure depends on the ability to trace, after the fact, what decision was made, by whom or by what, on the basis of what information, and with what review. A system in which AI decisions are not reconstructable, or in which the human-authoritative state is reconstructable only as a runtime promise that may have been disabled, is a system whose accountability evaporates at the moment accountability is needed. The response in current regulatory frameworks is to require *human oversight* of AI systems classified as high-risk. The EU AI Act Article 14 [1] mandates that high-risk AI systems be designed to permit effective human oversight throughout their deployment, with natural persons enabled to monitor the system, understand its outputs, detect anomalies, and disregard the system's output when judgment warrants. The FDA's AI/ML Software as a Medical Device action plan, the NHTSA framework for autonomous vehicle oversight, and the EASA concept paper on AI in aviation all require some form of human oversight for AI systems whose decisions have safety-of-life consequences. These regulatory frameworks specify *what* the human-AI relationship must permit. They do not specify *how* the system must be architected so that the permission is actually structural rather than policy-level. A system can satisfy EU AI Act Article 14 on paper while implementing override as a configuration flag the operator may or may not be able to invoke under operational stress. The present paper addresses the architectural gap: how should an adaptive AI orchestration system be designed so that human authority is a constitutional property of the system, not a runtime configuration? The architectural design principle is named here as *Supervisory Primacy*. The paper articulates the principle, distinguishes it from existing HITL taxonomies, identifies the architectural mechanisms that operationalize it, and illustrates the operationalization in MILO [3]. ## 2. Background and Related Work **EU AI Act Article 14 — Human Oversight.** Article 14 of the EU AI Act, the regulation that entered into force on 1 August 2024 [1] with high-risk-system obligations applying from 2 August 2026 (and from 2 August 2027 for high-risk AI systems embedded in regulated products), requires high-risk AI systems to be designed to enable effective human oversight by natural persons during the period in which the system is in use. The required capacities under Article 14(4) are: (a) properly understanding the high-risk AI system's capacities and limitations; (b) remaining aware of the tendency to over-rely on system outputs (automation bias); (c) correctly interpreting outputs; (d) deciding not to use the system or otherwise disregard, override, or reverse its outputs; and (e) intervening in the operation of the system or interrupting it through a "stop" function. (The broader monitoring obligation is set out in Article 14(2)–(3) rather than enumerated in 14(4).) Article 14 is the regulatory floor; it specifies what oversight must permit, not how the system must be architected to make the permission effective. **Parasuraman, Sheridan, and Wickens — Levels of Automation.** The canonical taxonomy of human-automation interaction [2] organizes automation into four stages (information acquisition, information analysis, decision/action selection, action implementation) along a continuum of automation levels, with the ten-level Sheridan–Verplank scale applied most directly to the decision/action-selection stage and ranging from full human control to full automation with no human intervention. The taxonomy is descriptive: it specifies what level of automation a given system implements. The taxonomy does not specify what level a high-consequence system *should* implement; that is a design choice. Supervisory Primacy operates within the Parasuraman-Sheridan-Wickens framework by pinning the default position at the human-authoritative end of the action-implementation stage for any class of action classified as consequential, and by specifying that the pin be implemented as an architectural property of the system rather than as a configuration parameter. **FDA, NHTSA, EASA — Sector-Specific Oversight Guidance.** Sector-specific regulatory frameworks have developed their own articulations of human oversight requirements: the U.S. Food and Drug Administration's *AI/ML Software as a Medical Device Action Plan* emphasizes total product life-cycle oversight for adaptive AI in medical devices [6]; the National Highway Traffic Safety Administration's Standing General Order on Crash Reporting for Automated Driving Systems requires reporting of crash events involving Level 2+ automation, establishing an operational data-collection regime for the human-system interaction [7]; the European Union Aviation Safety Agency's Concept Paper on AI in aviation specifies categorical levels of human-AI teaming with increasing AI autonomy bounded by increasing oversight requirements [8]. The frameworks differ in detail, but together they signal a regulatory direction in which the human-AI relationship for high-consequence systems must be documented with sufficient fidelity to permit post-hoc reconstruction. Supervisory Primacy adopts this direction as an architectural target: the audit trail is the system's substrate, not a logging feature added after the fact. **Industrial robotics and functional-safety standards.** For deployments involving physical actuation — industrial robots, collaborative robots, motion-control systems — the applicable safety standards are ANSI/RIA R15.06 [11], ISO 10218-1 and ISO 10218-2 [12] (industrial robot safety requirements for robots and for robot systems and integration, respectively), and ISO/TS 15066 [13] (collaborative-robot safety). At the functional-safety layer, IEC 61508 (electrical/electronic/programmable electronic safety-related systems) and IEC 61511 (process-industry safety instrumented systems) [14] specify the safety-integrity-level (SIL) framework against which safety-related functions are designed and validated. Supervisory Primacy is intended to compose with — not replace — these standards: the SIL-rated safety function (e.g., an emergency stop tied to a light curtain) remains the deterministic safety floor, while Supervisory Primacy governs the *consequential decision* layer above it (e.g., whether to start a robotic motion at all, on what authorization, and with what audit trail). The architectural substrate makes a SIL-rated safety event and a Supervisory Primacy authorization event part of the same reconstructable record. **Beer's Viable System Model and Supervisory Control.** Stafford Beer's Viable System Model [5] specifies the recursive cybernetic structure of viable systems, with each subsystem retaining identity and authority under environmental change. Supervisory Primacy is consistent with Beer's framework: the human operator occupies the position that, in Beer's structure, would be designated as System 5 (identity, policy, and purpose) — the seat of authority from which the system's responses to environmental disturbance are governed. ## 3. The Principle of Supervisory Primacy Supervisory Primacy is stated as follows: > *In an adaptive AI orchestration system deployed in a high-consequence domain, the human-authoritative state is the architectural default for any action classified as consequential. The AI proposes; the human disposes. Every consequential action carries a mandatory authorization audit trail recorded before the action dispatches. The eight non-negotiable operational integrity constraints (no coercion, individual baseline only, no surveillance, operator authority invariant, transparency, data sovereignty, override always, independent oversight) are implemented as enforceable safeguards in signed deployment builds rather than as runtime policy or configuration.* The principle is not a new taxonomy of human-AI interaction. It is the *architectural form* of human authority — the substrate that makes existing HITL taxonomies and existing regulatory oversight requirements operational under deployment stress. Supervisory Primacy does not invent the concept that humans should retain authority over AI decisions in high-consequence domains. It specifies the structural conditions under which the retention is mechanical rather than promissory. The principle has three architectural commitments. **Commitment 1 — Default state is human-authoritative.** For any class of action classified as consequential, the system's default action is to surface the proposed action to the human operator together with the AI's reasoning and recommendation. The default action is not execute-with-override-available; it is propose-pending-authorization. The distinction is structural: execute-with-override-available admits a race condition in which the action executes before the human can override; propose-pending-authorization eliminates the race because the action does not begin until authorization is recorded. **Commitment 2 — Audit trail by architecture, not by policy.** Every command issued in the system persists to a durable, append-only audit log before the command dispatches to its target [3]. If the process terminates between dispatch and execution, replay reconstructs exact state. The audit trail is the substrate, not a logging feature. The architectural pattern named *persist-before-deliver* — *every command persists before it dispatches; every signal persists before it fans out* — is the mechanism by which the system's behavior is reconstructable under arbitrary failure modes. **Commitment 3 — Integrity constraints are architectural-target enforceable safeguards.** The eight operational integrity constraints — *no coercion ever*, *individual baseline only*, *no surveillance architecture*, *operator authority is the invariant*, *operational transparency*, *data sovereignty*, *override always available*, *independent oversight* [4] — are specified as architectural commitments to be implemented as code-level invariants bound to the design specification and compiled into signed deployment builds for deployment-grade systems. The architectural target is that disabling any constraint should require rebuilding from source, not toggling a runtime flag — making compliance mechanical rather than promissory. Deployments that cannot satisfy all eight constraints are outside the permitted use boundary of the architecture by design. ## 3.1 The Latency-Budget Tradeoff Commitment 1 (default state is human-authoritative) imposes a latency budget that is the central design tension of Supervisory Primacy. The principle requires that consequential actions begin only after the human has recorded authorization. If the latency budget for authorization is too long (seconds of operator response time per consequential action), the system cannot keep up with the operational tempo of the environment; routine actions become operationally infeasible. If the latency budget is too short (the operator has only a millisecond to react), the human authorization becomes a rubber stamp and Supervisory Primacy degrades into automation with theatrical human-in-the-loop. The principle is meaningful only when the consequence classification of an action is calibrated such that the operational tempo at that classification matches the latency budget available to the human. Routine actions, by definition, should not be classified as consequential; consequential actions, by definition, should occur at a tempo compatible with deliberate human authorization. The architectural design choice is therefore the *consequence classification itself* — what does and does not count as consequential — rather than the override mechanism. This relates closely to consequence-graded authorization in industrial control environments, where the latency budget for human authorization is dictated by the operational tempo at the action's consequence tier rather than by a uniform per-command policy. ## 4. Architectural Mechanisms The principle of Supervisory Primacy is operationalized through four architectural mechanisms, each implemented in MILO and illustrated here at the public-architecture-metaphor level. The four mechanisms are not selected because they happen to exist in MILO; they are selected because each one resolves a question that human-in-the-loop architecture must answer regardless of implementation. *Audit-first command flow* answers *"what did the human authorize, and in what context"* under arbitrary failure modes. *Reflex Arcs Run Before Fanout* answers *"what response is faster than human reaction time, and how is that response architecturally bounded so it does not escape human authority."* *Pre-execution gating* answers *"at what specific architectural point does authorization happen, and what are the permitted outputs of that decision."* *Voluntary side-effect pathway* answers *"how does the architecture prevent runaway action sequences from a single human decision."* The four mechanisms are HITL-specific in the sense that each one addresses a structural problem of human-AI authority allocation that exists in any HITL architecture; the MILO implementations are concrete instances of solutions, not the only possible solutions. [FIGURE_1] **Mechanism A — Audit-first command-and-signal substrate.** The orchestrator implements three load-bearing patterns: every command travels down a single command bus to its target, every signal travels up a single signal bus to its subscribers, and every message is audited *before* it is delivered [3]. The pattern is not a logging convenience; it is the substrate that makes Commitments 1, 2, and 3 mechanically enforceable rather than promissory. The audit substrate is required to be append-only and durable so the trail survives arbitrary process termination. At the framework level, append-only continuity — not cryptographic tamper-evidence — is the *minimum* architectural property required for post-hoc reconstructability; hardening is a separate architectural commitment described in the threat model below. **Audit-substrate threat model.** The entire architecture rests on audit-trail integrity, so the substrate is itself a high-value attack target. Append-only continuity at the orchestrator is the minimum property and is necessary but not sufficient against a sophisticated attacker — particularly an insider with administrative access to the host. For high-consequence deployments, the framework requires three additional architectural commitments: (a) **cryptographic chain-of-custody** — each audit record is signed and chained (hash-linked) so silent tampering is detectable; (b) **custodial separation** — the audit-log writer and the audit-log custodian are distinct services owned by different operational roles, so no single principal can both produce and curate the record; and (c) **external WORM replication** — every audit record is streamed in near-real-time to an independent write-once, read-many sink under separate administrative control (cf. NIST SP 800-92 [10] on log management and NIST SP 800-53 control AU-9 on protection of audit information). Deployments that cannot satisfy all three commitments do not meet the high-consequence deployment posture and are outside the permitted use boundary of the architecture for those environments. **Mechanism B — Reflex Arcs Run Before Fanout.** Critical signals (e.g., safety-relevant anomalies) are evaluated by reflex predicates before the signal fans out to general subscribers [3]. A reflex may halt the system before the human is informed of the underlying signal, mirroring the spinal-cord reflex that fires before the brain is aware of the stimulus. This pattern admits a specific class of action — emergency halt — that operates faster than human reaction time but remains architectural: the reflex dispatches a halt command through the same audited command bus as any other command, with end-to-end audit entries from critical signal through reflex through halt-executor. The pattern preserves Supervisory Primacy under emergency conditions: the human cannot react faster than the reflex, but every reflex action is auditable, reversible (by resume command), and bounded by Commitment 3's integrity constraints. **Mechanism C — Pre-Execution Gating.** Every consequential action is gated through a pre-execution validator with three outputs: *allow* (logged), *hold/block* (with plain-language operational explanation), or *recommend* (safer alternative) [4]. The pattern surfaces the AI's reasoning at the moment of decision rather than reconstructing it post-hoc. The pattern admits the human override at every gate, with the override logged for audit but never used to trigger adverse personnel or operational consequences (Commitment 3, integrity constraint #7). **Mechanism D — Voluntary Pathway for Side Effects.** The architectural pattern explicitly excludes auto-chaining: the orchestrator does not automatically follow a completion signal with a subsequent action [3]. The human-authoritative state is required to re-enter for any subsequent consequential action. The pattern prevents the runaway sequence in which the AI's first action triggers a chain of subsequent actions before the human can intervene. The pattern is voluntary in the architectural sense: side effects require explicit commanding, not automatic propagation. ## 5. Relationship to Existing HITL Taxonomies Supervisory Primacy operates within the Parasuraman-Sheridan-Wickens framework [2] by pinning the default position at the human-authoritative end of the action-implementation stage for consequential actions. The pin is structural rather than configurable. The principle does not displace the taxonomy; it specifies where in the taxonomy a high-consequence adaptive AI orchestrator should be designed to operate by default. Relative to the EU AI Act Article 14 [1], Supervisory Primacy operates as the architectural substrate by which the regulation's required oversight capacities (the five Article 14(4) capacities — understanding limits, automation-bias awareness, correct interpretation, disregard, and interruption — together with the general monitoring obligation in Article 14(2)–(3)) become operationally effective rather than merely permitted. A system that satisfies Article 14 on paper but implements override as a configuration flag fails Supervisory Primacy; a system that implements override through the audit-first command bus with the eight integrity constraints as enforceable safeguards satisfies both. Relative to sector-specific oversight guidance (FDA, NHTSA, EASA), Supervisory Primacy provides a common architectural substrate across sectors. The substrate does not specify sector-specific risk classifications or decision authority allocations — those remain sector-specific. The substrate ensures that whatever allocation a sector regulator specifies is structurally implemented rather than policy-implemented. ## 6. Implications and Discussion Supervisory Primacy has implications for the design, evaluation, and deployment of adaptive AI orchestration systems in high-consequence domains. For *design*, the principle implies that the architectural choices made before any AI model is trained — the command bus, the audit substrate, the integrity-constraint enforcement mechanism, the reflex layer, the voluntary side-effect pathway — bound the system's eventual capacity to support effective human oversight more tightly than any subsequent regulatory compliance retrofit can recover. A system designed for execute-with-override-available cannot be converted into a propose-pending-authorization system without rebuilding the substrate. For *evaluation*, the principle implies that the conventional evaluation metrics for AI systems — accuracy, latency, throughput — are necessary but insufficient. An adaptive AI orchestration system in a high-consequence domain must be evaluated additionally on: (a) audit-trail completeness under arbitrary process termination; (b) the structural enforceability of the integrity constraints (can they be disabled at runtime, or do they require rebuilding from source?); (c) the architectural enforceability of the voluntary side-effect pathway (does the system auto-chain, or does it require explicit re-commanding?); (d) the latency and audit fidelity of the human override pathway under operational stress. For *deployment*, the principle implies that high-consequence domains — energy grid control rooms, nuclear facility operations, advanced manufacturing under operator supervision, autonomous robotics with human-robot interface, satellite and space operations, first-responder coordination — should not deploy adaptive AI systems whose Supervisory Primacy commitments are policy-level rather than architectural. The submission of MILO under the U.S. Department of Energy's Genesis Mission [4] is intended to make a viable-architecture alternative available to those domains. ## 6.1 Limitations The principle is articulated at the architectural-design level. Three specific limitations bound the present contribution: (i) the consequence classification of an action (the central design tension named in §3.1) is specified as a deployment-time activity and no canonical taxonomy is offered; (ii) the audit-substrate hardening commitments (§4, "Audit-substrate threat model") are specified as architectural requirements but their composition with specific cryptographic chain-of-custody implementations (e.g., AWS QLDB, Sigstore-style transparency logs, blockchain-anchored audit logs) is not benchmarked here; (iii) the composition with the industrial-robotics functional-safety standards [11]–[14] is asserted at the principle level and not validated against any SIL-rated safety case. Quantitative validation — operator-override latency under operational stress, audit-trail completeness under adversarial process termination, and incident-reconstruction fidelity against actual sociotechnical-failure post-mortems — is forthcoming work and is not claimed here. The submission of MILO under the U.S. Department of Energy's Genesis Mission [4] is under review; no acceptance or grant outcome is claimed. ## 7. Conclusion This paper has introduced Supervisory Primacy as the architectural design principle by which human authority over consequential AI decisions becomes a constitutional property of an adaptive AI orchestration system rather than a runtime configuration. The principle is consistent with EU AI Act Article 14 [1], operates within the Parasuraman-Sheridan-Wickens levels-of-automation framework [2], aligns with NIST AI RMF 1.0 Appendix C on human-AI interaction [9], and is illustrated using MILO [3], the author's working orchestrator submitted under the U.S. Department of Energy's Genesis Mission [4]. The contribution is at the architectural level: Supervisory Primacy is not a new HITL taxonomy; it is the structural design — audit-first command flow, reflexes before fanout, pre-execution gating, voluntary side-effect pathway, and integrity constraints as architectural-target safeguards in signed builds — that makes human oversight load-bearing rather than retrofittable. The principle's failure modes are mechanical (an audit trail with a gap, a runtime flag that disables an integrity constraint, an auto-chain pathway, an opaque resolver in the command bus); its successes are mechanical (an unbroken audit trail, a structurally inviolate integrity constraint, an explicit voluntary side-effect pathway, a transparent command bus with single-target dispatch). Related architectural directions by the author — independence-verifiable multi-source cryptographic entropy, latency-aware authentication in industrial control, structural principles for adaptive AI architecture, and the discipline of viability under non-stationary conditions — each inherit Supervisory Primacy as a constitutional property. --- ## Data Availability All architectural materials, source manuscripts, the reference implementation, and accompanying figures are openly available at https://github.com/jmontano1/milo-architecture and permanently archived at Zenodo (DOI: [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025)). No private datasets are referenced; the architectural framework itself is the subject of this paper. Patent rights for the underlying MILO software architecture are reserved; the ~MILO trademark is held under USPTO Serial No. 99706004 (intent-to-use, Class 009). ## References [1] European Union, *Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)*, Article 14 (Human Oversight), Aug. 2024. [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [2] R. Parasuraman, T. B. Sheridan, and C. D. Wickens, "A model for types and levels of human interaction with automation," *IEEE Transactions on Systems, Man, and Cybernetics — Part A: Systems and Humans*, vol. 30, no. 3, pp. 286–297, May 2000. doi:10.1109/3468.844354 [3] J. E. Flores Montano, *MILO (Modular Intelligent Learning Orchestrator)*, JM Automated Solutions. Patent pending. Submitted under the U.S. Department of Energy Genesis Mission, 2026. [4] U.S. Department of Energy, "The Genesis Mission: Transforming Science and Energy with AI," Office of the Under Secretary for Science, Executive Order 14363, November 2025. [Online]. Available: https://www.energy.gov/genesis [5] S. Beer, *Brain of the Firm*, 2nd ed. Chichester, UK: Wiley, 1981. [6] U.S. Food and Drug Administration, *Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) Action Plan*, FDA, Jan. 2021. [7] National Highway Traffic Safety Administration, *Standing General Order 2021-01 on Crash Reporting for Vehicles Equipped with Automated Driving Systems and Level 2 Advanced Driver Assistance Systems*, NHTSA, Jun. 2021 (Second Amendment effective May 15, 2023). [8] European Union Aviation Safety Agency, *Concept Paper: Guidance for Level 1 & 2 Machine Learning Applications*, EASA AI Roadmap, Issue 02, Mar. 2024. [9] E. Tabassi, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1, National Institute of Standards and Technology, Jan. 2023, Appendix C: AI Risk Management and Human-AI Interaction. doi:10.6028/NIST.AI.100-1 [10] K. Kent and M. Souppaya, *Guide to Computer Security Log Management*, NIST SP 800-92, National Institute of Standards and Technology, Sep. 2006. doi:10.6028/NIST.SP.800-92 [11] R. Y. Wang and U. Karaman, *ANSI/RIA R15.06: American National Standard for Industrial Robots and Robot Systems — Safety Requirements*, American National Standards Institute / Robotic Industries Association, 2012 (R2020). [12] International Organization for Standardization, *ISO 10218-1: Robots and robotic devices — Safety requirements for industrial robots — Part 1: Robots*, ISO, 2011 (revised 2025); and *ISO 10218-2: Part 2: Robot systems and integration*, ISO, 2011 (revised 2025). [13] International Organization for Standardization, *ISO/TS 15066: Robots and robotic devices — Collaborative robots*, ISO, 2016. [14] International Electrotechnical Commission, *IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems*, IEC, 2010; and *IEC 61511: Functional safety — Safety instrumented systems for the process industry sector*, IEC, 2016. --- ## About the author Jorge Enrique Flores Montano (ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418); jmontano@jmautomated.com) is the founder of JM Automated Solutions and the inventor of MILO. A full biography is maintained at [https://www.milo-usa.com/jorge-enrique-flores-montano](https://www.milo-usa.com/jorge-enrique-flores-montano). ## Conflict of Interest and Funding Disclosure The author is the inventor of MILO (patent pending) and the founder of JM Automated Solutions. The principle proposed in this paper is a contribution from a working development program in which the author retains sole authorship and inventive interest. No external funding was received for the preparation of this manuscript. The author retains all rights to MILO and to the principle articulated herein. ## Appendix A — About MILO MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture organized into discrete, single-responsibility subsystems under a strict separation-of-concerns discipline. An audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, producing an append-only audit trail that survives arbitrary process termination. The architecture is designed for *viability* — operational continuity under non-stationary conditions — rather than for prediction accuracy against an expected future. ### Eight structural principles Six are established physical, informational, control-theoretic, and statistical laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems. 1. **Second Law of Thermodynamics** — entropy treated as an architectural diagnostic signal, not a fault to be suppressed. 2. **Ashby's Law of Requisite Variety** — a regulator must possess variety at least equal to the system it regulates; implemented as a fleet of specialist agents matching the operational domain. 3. **Shannon Information Theory** — variance reduction occurs at the signal-carrier level, not redundantly at each consumer. 4. **Principle of Least Action — Single-Target Dispatch** — every command has one explicit target; no implicit resolvers, no opaque dispatchers. 5. **Lyapunov-Style Bounded Response** — every adaptive subsystem admits an explicit halt-and-resume pathway; adaptation that drifts unboundedly is failure, not learning. 6. **Power-Law Distribution Architecture** — engineered for the 99th-percentile event, not the median. 7. **Individual-Baseline Variance Modeling** *(original framework)* — operator-layer interventions calibrated against the individual's own established performance baseline, never a population norm. Design-stage; pending empirical validation. 8. **Precision Perturbation Without Variance Compression** *(original framework)* — operator-layer interventions shift probability mass toward high-reliability decision outputs while preserving operator authority and the variability that *is* the operator's adaptive intelligence. Design-stage; pending empirical validation. ### Eight operational integrity constraints Architectural commitments designed to be implemented as enforceable safeguards in deployment builds — not as runtime policy. Disabling any constraint should require rebuilding from source, not toggling a flag. 1. **No coercion, ever** — the system issues recommendations, never compels. 2. **Individual baseline only** — measurements against the operator's own baseline; never against a population norm or productivity target. 3. **No surveillance architecture** — performance-support tool, not a monitoring infrastructure. 4. **Operator authority is the invariant** — the system expands effective decision options; it never narrows or preempts them. 5. **Operational transparency** — every recommendation includes a plain-language explanation. 6. **Data sovereignty** — operator-layer data belongs to the institutional program under documented data governance. 7. **Override always available** — overrides are logged for audit but never used for adverse personnel action. 8. **Independent oversight** — operator-layer deployments require institutional ethics-board review, published consent frameworks, and periodic third-party audits. ### Unifying principle > *MILO does not predict the future. It remains viable in any future.* The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle. ### Trademark, patent, and submission status - **Mark.** *~MILO™* — U.S. Patent and Trademark Office Serial No. 99706004; filed March 16, 2026; intent-to-use; International Class 009 (downloadable AI software). The leading tilde disambiguates from senior MILO marks held by unrelated owners in different International Classes. - **Patent.** Patent application pending for the underlying software architecture. Implementation may require a patent license once issued; nothing in this document or its CC BY 4.0 license on the manuscript text grants any patent license. - **Federal submission.** Submitted to the U.S. Department of Energy under the *Genesis Mission* (Executive Order 14363, November 2025); currently under review. No acceptance or grant outcome is claimed. - **Concept DOI.** [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025) — Zenodo, persistent across versions. - **Public reference.** [https://github.com/jmontano1/milo-architecture](https://github.com/jmontano1/milo-architecture). - **Author contact.** Jorge Enrique Flores Montano · jmontano@jmautomated.com · ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418). # Article 04: Eight Structural Principles --- title: "Eight Structural Principles for Adaptive AI Architecture" subtitle: "From Physical Law and Cybernetics to Engineering Constraints on Viable Adaptive Systems" author: "Jorge Enrique Flores Montano" author_aliases: ["Jorge Flores Montano", "Jorge Montano", "Jorge E. Flores Montano", "J. E. Flores Montano"] affiliation: "JM Automated Solutions" date: 2026-05-11 description: "Eight engineering principles that bound the design space of viable adaptive AI architectures: six established physical and informational laws applied as architectural constraints (Second Law of Thermodynamics, Ashby's Law of Requisite Variety, Shannon Information Theory, Principle of Least Action, Lyapunov-style bounded response, Power-Law Distribution Architecture), plus two original frameworks proposed by the author for the operator-cognitive performance layer: Individual-Baseline Variance Modeling and Precision Perturbation Without Variance Compression." keywords: - MILO - Modular Intelligent Learning Orchestrator - Jorge Flores Montano - Jorge Montano - Jorge Enrique Flores Montano - JM Automated Solutions - adaptive AI architecture - structural principles - architectural constraints - cybernetics - Ashby's Law of Requisite Variety - Shannon Information Theory - Lyapunov stability - antifragility - power law distribution - Friston Free Energy Principle - Beer Viable System Model - Individual-Baseline Variance Modeling - Precision Perturbation Without Variance Compression - operator cognitive state - DOE Genesis Mission - patent pending - critical infrastructure - U.S. national interest tags: - milo - adaptive-ai-architecture - structural-principles - cybernetics - ashby-law - shannon-information-theory - lyapunov-stability - antifragility - jorge-flores-montano - jm-automated-solutions - doe-genesis-mission - patent-pending - critical-infrastructure - operator-cognitive-modeling article_number: 4 series_name: "MILO Architectural Series" series_total: 5 canonical_url: "https://www.milo-usa.com/articles/04-eight-structural-principles" trademark: "~MILO™ is a trademark of Jorge Enrique Flores Montano (USPTO Serial No. 99706004)" patent_status: "Patent Pending" copyright: "© 2026 Jorge Enrique Flores Montano / JM Automated Solutions" --- # Eight Structural Principles for Adaptive AI Architecture **Subtitle:** From Physical Law and Cybernetics to Engineering Constraints on Viable Adaptive Systems **Author:** Jorge Enrique Flores Montano · Founder, JM Automated Solutions **~MILO™** — Modular Intelligent Learning Orchestrator (patent pending) **Publication date:** May 2026 --- ## Abstract Adaptive artificial-intelligence systems are described in vague terms — *self-improving*, *resilient*, *agentic* — that obscure the structural constraints under which such systems can actually be viable. This paper identifies eight principles that bound the design space of adaptive AI architectures. Six are established physical and informational laws — the Second Law of Thermodynamics, Ashby's Law of Requisite Variety, Shannon's information theory, the Principle of Least Action, Lyapunov stability, and the power-law distribution of system events. Two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems: *Individual-Baseline Variance Modeling* and *Precision Perturbation Without Variance Compression*. The eight principles operate as architectural design constraints, not as a theory of intelligence. The first six are illustrated with their operational form inside MILO, a patent-pending adaptive AI orchestrator developed by the author and submitted to the U.S. Department of Energy under the Genesis Mission; the seventh and eighth are v.5 design-stage frameworks, not shipped operator-monitoring features. The synthesis is consistent with, and complementary to, Friston's Free Energy Principle, Beer's Viable System Model, and recent thermodynamics-adjacent AI work; it differs in that the eight principles are used as design-time constraints on architectural choices, not as a unified explanation of intelligence. **Keywords:** adaptive AI, architectural constraints, cybernetics, Lyapunov-style bounded response, antifragility, human-in-the-loop, industrial AI orchestration. **Highlights.** - Identifies eight structural principles that bound the design space of viable adaptive AI architectures, drawn from established physical, informational, control-theoretic, and statistical lineages. - Six principles apply established external laws (Second Law of Thermodynamics, Ashby's Law of Requisite Variety, Shannon Information Theory, Principle of Least Action, Lyapunov-style bounded response, Power-Law distribution). - Two original frameworks proposed by the author for the operator-cognitive performance layer: *Individual-Baseline Variance Modeling* and *Precision Perturbation Without Variance Compression* — flagged as design-stage, pending empirical validation. - Synthesis is positioned as complementary to Friston's Free Energy Principle and Beer's Viable System Model but distinct — design-time constraints on architectural choices, not a unified theory of intelligence. **Index Terms:** adaptive AI architecture, structural principles, cybernetics, control theory, Lyapunov stability, Ashby's Law of Requisite Variety, Shannon Information Theory, antifragility, Power-Law distribution, operator-cognitive modeling, viable system model. **Plain Language Summary.** Adaptive AI systems are often described in vague terms — *self-improving*, *resilient*, *agentic* — that obscure what makes some such systems viable and others fragile. This paper identifies eight engineering principles that constrain the design space of viable adaptive AI architectures. Six are established physical and informational laws (thermodynamic entropy, Ashby's variety law, Shannon information theory, the principle of least action, Lyapunov-style bounded response, and the power-law distribution of system events) applied here as architectural design constraints rather than as theories of intelligence. Two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems: *Individual-Baseline Variance Modeling* and *Precision Perturbation Without Variance Compression*. The eight principles, taken together, separate adaptive AI orchestrators that survive operational stress from those that fail it. **Relevance to U.S. National Interest.** The principles articulated here apply directly to the AI-enabled critical-infrastructure environments identified by the DOE Genesis Mission — advanced manufacturing, grid reliability, autonomous systems, nuclear-facility operations, and human-in-the-loop AI for high-consequence decision support. Adaptive AI deployed in those environments without these architectural constraints carries failure modes that the constraints were established to prevent. **Status of claims.** Six of the eight principles in this paper apply established physical and informational laws as architectural design constraints: the Second Law of Thermodynamics, Ashby's Law of Requisite Variety [6], Shannon Information Theory [7], the Principle of Least Action, Lyapunov stability [8], and the Power-Law distribution of complex-system events [9]. The mapping of each principle to a specific orchestrator-level architectural choice is the author's contribution and is subject to further validation; the laws themselves are external references. Principles 7 and 8 — *Individual-Baseline Variance Modeling* and *Precision Perturbation Without Variance Compression* — are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems and are flagged in the paper as design-stage frameworks pending empirical validation in shipped deployments. The synthesis is consistent with prior work by Friston [3], Beer [4], and the thermodynamic-AI literature [5]; differences are explicit in §2 and §5. This manuscript is a preprint prior to peer review. **About MILO.** MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture for high-consequence critical-infrastructure environments. The full architectural reference — eight structural principles, eight operational integrity constraints, the unifying viability principle, and the trademark/patent status — is maintained as a single canonical document at https://github.com/jmontano1/milo-architecture (concept DOI: 10.5281/zenodo.20117025). Author contact: jmontano@jmautomated.com. --- ## 1. Introduction Adaptive AI architecture is most often described in language drawn from the system's marketing rather than its physics. A system is *self-improving* because its developers say so; it is *resilient* because it has not yet failed visibly; it is *agentic* because it issues commands. These descriptors are claims about capability, not about structural form. They do not tell an engineer whether the system can survive a perturbation it was not trained for, whether its internal variety matches the variety of the environment it governs, whether its informational paths admit auditable decisions, or whether its adaptation has any bounded stop condition. The history of engineering offers a better discipline. Physical and informational systems are not viable because they are aspirationally well-intentioned; they are viable because their architecture obeys constraints that have been established for decades — in thermodynamics, in classical mechanics, in cybernetics, in control theory, in information theory, and in the empirical statistics of complex systems. An adaptive AI architecture that ignores those constraints inherits failure modes the constraints were discovered to prevent. This paper identifies eight such principles and argues that they constitute structural constraints on the design space of viable adaptive AI systems. Six are established laws applied as architectural design constraints. Two are original frameworks proposed by the author for the operator cognitive performance layer of high-consequence industrial systems, where human decision context, cognitive load, fatigue, and task-state misalignment can become material sources of operational variance. The eight principles are illustrated using MILO (Modular Intelligent Learning Orchestrator), a patent-pending adaptive AI orchestration system [1] that the author has developed and submitted to the U.S. Department of Energy under the Genesis Mission [2]. MILO is the working substrate for the first six principles and the design substrate for the proposed v.5 operator-layer extension; the paper's contribution is the principles, not the implementation. Where MILO is referenced, it is referenced at the architectural level only. The paper does not propose a new theory of intelligence. Several frameworks — Friston's Free Energy Principle and Active Inference [3], Beer's Viable System Model [4], and thermodynamics-adjacent AI explanation work [5] — already address broader explanatory or diagnostic layers. The contribution here is narrower and more practical: a set of design-time architectural constraints that, taken together, separate viable adaptive AI orchestrations from systems that merely claim viability. ## 2. Background and Related Work The eight principles draw from five established intellectual lineages. The Second Law of Thermodynamics, formalized by Clausius and refined by Boltzmann, established entropy as the directional quantity governing closed-system evolution. Ashby's Law of Requisite Variety [6], introduced in 1956 cybernetics, established that a regulator must possess variety at least equal to the system it regulates. Shannon's information theory [7], introduced in 1948, established the channel-capacity bounds on noise-tolerant communication. The Principle of Least Action, developed by Maupertuis, Lagrange, and Hamilton, established that physical systems traverse trajectories of minimum action. Lyapunov stability [8], introduced in 1892, provided the formal mathematical condition for bounded return-to-equilibrium under perturbation. Power-law statistics in complex systems, formalized in modern form by Clauset, Shalizi, and Newman [9], established that heavy-tailed empirical distributions dominate the consequence-profile of complex-system events. These five lineages have been applied to AI in adjacent but distinct ways. Friston's Free Energy Principle [3] proposes a unified explanation of self-organizing systems combining information-theoretic and thermodynamic primitives. Beer's Viable System Model [4] applies Ashby's variety law and cybernetic feedback to recursive viable organizations and autonomous systems. Thermodynamics-inspired AI work [5] has recently used thermodynamic concepts to explain black-box model behavior. Antifragility, introduced by Taleb [10], formalizes the inverted Jensen inequality under heavy-tailed payoff distributions and provides a structural account of systems that benefit from bounded disorder, variation, and stressors. The contribution of the present paper differs from each of these. It is not a theory of intelligence (as in [3]), not a replacement for recursive viable-system cybernetics (as in [4]), not a thermodynamic explanation of AI behavior (as in [5]), and not a payoff-distribution analysis (as in [10]). It identifies the architectural choices an adaptive AI orchestration system must make and shows that each of the eight principles constrains those choices. The contribution is at the level of engineering design, not at the level of theoretical foundation. The two original frameworks (Sections 3.7 and 3.8) extend the synthesis into the operator-cognitive performance layer — a domain where prior work in human factors and adaptive automation [11], [12] has identified the problem but has not articulated this architectural form of the solution. ## 3. The Eight Structural Principles The eight principles are organized in two groups. Sections 3.1 through 3.6 present the six established laws applied as architectural constraints. Sections 3.7 and 3.8 present two original frameworks proposed by the author for the operator-cognitive performance layer. Each principle is stated, its architectural form is identified, and the failure mode it prevents is named. [FIGURE_1] **Selection criterion.** The eight principles are selected against two filters. *(i)* The principle has a well-developed mathematical or empirical foundation in its native field — thermodynamics, cybernetics, information theory, classical mechanics, control theory, complex-systems statistics, or (for Principles 7 and 8) cognitive science. *(ii)* The principle has an operational architectural form: a design choice in an adaptive AI orchestration system whose specification can be falsified by observing the system's runtime behavior. Other foundational principles — conservation laws, symmetry principles, dissipation theorems — satisfy filter (i) but, in the author's assessment, are difficult to operationalize as architectural design constraints at the orchestration scale. The eight selected are not claimed to be the complete set of foundational principles applicable to adaptive AI; they are the set for which the author can articulate both the foundation and the architectural form. The framework is open to extension if additional principles meeting both filters are subsequently identified. **Scope and intent of this paper.** The present paper is a *perspective paper* — a synthesis and map across foundations, not a deep treatment of any single principle. Each of the eight principles merits its own dedicated technical paper that develops the principle's operational architectural form in greater mathematical and empirical detail than space permits here. The contribution of the present paper is the synthesis: the identification of which principles bound the design space of adaptive AI orchestration and how each maps to an operational design choice. Readers seeking deeper treatment of any individual principle should expect that to be the subject of subsequent work. **Orthogonality and overlap among the principles.** The eight principles are not strictly orthogonal in the mathematical sense; some derive from or are formally related to others. Most notably, Ashby's Law of Requisite Variety (Principle 2) can be derived from Shannon's Theorem 10 [7], making Principles 2 and 3 formally related rather than independent. Lyapunov-style bounded response (Principle 5) and the thermodynamic-entropy diagnostic (Principle 1) share the structural concern of bounded behavior under perturbation, viewed from different physical primitives. The principles are presented as eight because each has a distinct operational architectural form even where the underlying foundations are interrelated; the architecture of an adaptive AI orchestrator that satisfies all eight is structurally over-determined in a deliberate way, with overlapping constraints reinforcing one another rather than redundantly stating the same requirement. ### 3.1 Principle 1 — Second Law of Thermodynamics: Entropy as Architectural Diagnostic The Second Law establishes that closed systems trend toward maximum entropy. Applied as an architectural constraint, the principle requires that entropy be treated as a *diagnostic signal* about system state, not as a fault condition to be suppressed. Architecturally, this implies modular construction in which each component can be observed for entropy drift independently, and in which any component can be replaced without systemic collapse. In MILO, security drift is detected by an integrity-monitoring subsystem, carried by the audit-first signal substrate, and addressed by a bounded incident-response pathway — entropy is observed and responded to as information about state. The architectural consequence is that no subsystem may be a single point of failure; the failure mode prevented is the monolithic redeploy required to repair a single drifted component. ### 3.2 Principle 2 — Ashby's Law of Requisite Variety Ashby's law states that a regulator must possess variety at least equal to the variety of the system it regulates [6]. Applied as an architectural constraint, the principle requires that an AI orchestrator enumerate response options spanning the operational variety it is meant to govern. Implementation by a single generalist agent is structurally insufficient when the operational domain admits distinguishable subdomains; the orchestrator must instead operationalize a fleet of specialist agents whose combined variety matches the domain. In MILO, a fleet of specialist agents — each registered with a single explicit role covering an operational subdomain — provides the requisite variety against the domains the orchestrator governs; adding variety is structurally simple, since adding an agent is one new fleet entry while routing changes remain localized. The failure mode prevented is the AI orchestrator with five canned responses attempting to govern a domain of fifty distinguishable states. ### 3.3 Principle 3 — Shannon Information Theory: Variance Reduction at the Architectural Level Shannon's information theory bounds the noise-tolerant capacity of any communication channel [7]. Applied as an architectural constraint, the principle requires that variance reduction occur at the carrier level — the signal infrastructure itself — rather than being redundantly implemented at each consumer. Architecturally, this implies a persistent, fanout-aware signal bus that admits reflex-level interception before subscriber delivery. In MILO, the signal substrate persists each signal, evaluates reflex predicates, then fans out to subscribers; reflex arcs run before fanout, short-circuiting high-severity events at the carrier level. The failure mode prevented is every consumer reinventing its own noise filter and disagreeing about what is signal. ### 3.4 Principle 4 — Principle of Least Action: Single-Target Dispatch The Principle of Least Action establishes that physical trajectories minimize the action integral. Applied as an architectural constraint, the principle requires that the orchestration path between origin (the human operator's intent) and target (the responsible component) admit minimum informational cost — concretely, no hidden routing layer, no implicit resolver, no opaque dispatcher. In MILO, every command has one explicit target; the command bus persists the command, looks up the target, and invokes the single registered handler. The architectural patterns are *explicit-target dispatch* and *persist-before-deliver*: one command, one target, audited before dispatch [1]. The failure mode prevented is command routing through an opaque resolver where failures cannot be traced to a specific dispatch — the failure mode the author observed in pre-MILO orchestration that motivated the rebuild. ### 3.5 Principle 5 — Lyapunov-Style Bounded Response Lyapunov's foundational work on stability [8] provides the formal mathematical condition for bounded return-to-equilibrium under perturbation. The architectural application here is the weaker but operationally important *Lyapunov-style bounded response*: the principle requires that any adaptive subsystem admit a bounded response to disturbance — concretely, an explicit halt-and-resume pathway that can be invoked when the subsystem departs its equilibrium zone — without claiming a formal Lyapunov-function analysis of the orchestrator's full state space. In MILO, an emergency-halt reflex detects critical signals, dispatches a halt command through the command bus, and symmetrically supports a resume command; every halt and resume traverses the same audited dispatch path as any other command, with end-to-end audit entries from critical signal through reflex through halt-executor. The architectural consequence is that adaptation which drifts unboundedly is not learning, it is failure; the failure mode prevented is positive-feedback runaway in an *"adaptive"* loop that has no architectural stop condition. ### 3.6 Principle 6 — Power-Law Distribution Architecture: Tail-Event Preparedness Principle 6 differs from Principles 1 through 5 in epistemic status. Heavy-tailed distributions are an *empirical regularity* observed across many complex-system domains rather than a derived physical or mathematical law in the strict sense. Inclusion here is justified under filter (ii) of the selection criterion above: heavy-tailed consequence profiles in adaptive AI orchestration are an architectural design constraint with operational form (engineered for the 99th-percentile event), regardless of whether the underlying empirical regularity rises to the status of a law in the philosophical sense. Empirical statistics in complex systems show that heavy-tailed distributions dominate consequence profiles [9]. Applied as an architectural constraint, the principle requires that an adaptive AI orchestrator be engineered for the 99th-percentile event, not the median. Architecturally, this implies rolling-window degradation detection (rather than threshold-only alarms), periodic self-monitoring on a bounded cadence (rather than operator-triggered checks), and bounded reporting (top-N source ranking) to prevent flooding under tail events. In MILO, an integrity-monitoring subsystem implements all three: a health monitor with rolling-window error-and-critical detection per source, a periodic self-monitoring scheduler on a bounded cadence, and a signal aggregator that ranks sources by cumulative count without flooding the dashboard. The architectural consequence is design for the tail, not the median; the failure mode prevented is the system that meets 50th-percentile SLO and catastrophically fails at the 99th. This principle invokes the related concept of *antifragility* [10]: bounded variation and disorder that can improve a system rather than merely degrading it. The present framing treats antifragility as an architectural property of the orchestrator's adaptive-learning loop, not as a generalized claim about humans inside the system; the application of antifragility-style framings to operators is addressed in Section 3.8 and Section 4 with explicit governance constraints. ### 3.7 Principle 7 — Individual-Baseline Variance Modeling (Original Framework) **Status — original framework proposed by the author.** Sections 3.7 and 3.8 introduce frameworks proposed by the author for the operator-cognitive performance layer of high-consequence adaptive AI orchestration systems. These frameworks have been submitted to the U.S. Department of Energy under the Genesis Mission [2] and are under active development. The discussion below is at the principle level. Established human-factors research has long documented that human error and operator performance vary across shifts, roles, environmental conditions, training histories, and task contexts [13], [14]. The original framework proposed here is the architectural application: an adaptive AI orchestration system that intervenes on the operator-cognitive performance layer must model variance against the individual operator's own established performance baseline, not against a population norm. The architectural form of the principle is: *Interventions are calibrated to the individual's measured deviation from their own optimal performance state, established over a defined baseline window and recalibrated on a defined cadence.* The failure mode prevented is the AI system that misfires on operators whose individual baseline differs legitimately from a population norm. The framework operates under the operational integrity constraints of *individual consent*, *individual-baseline-only measurement*, *no surveillance architecture*, and *operator authority as the architectural invariant* [1]. Implementation in operational systems requires institutional ethics review, published consent frameworks, and periodic third-party audits of system influence patterns and operational outcomes. ### 3.8 Principle 8 — Precision Perturbation Without Variance Compression (Original Framework) **Status — original framework proposed by the author.** Established cognitive-science and human-reliability work supports probabilistic modeling of human state, workload, and decision reliability [3], [12]. The original framework proposed here is the architectural intervention category: *precision perturbation* — a class of intervention that shifts probability mass in the operator's cognitive state distribution toward high-reliability decision outputs without overriding operator authority and without compressing the essential variability required for adaptive operational judgment. The framework is the explicit architectural inverse of two failure modes commonly observed in operator-facing AI systems: (a) override-style interventions that bypass operator authority and (b) compression-style interventions that drive operators toward homogeneous decision states, eliminating the variability that *is* the operator's adaptive intelligence. The architectural form of the principle is: *Interventions are calibrated as precision perturbations to the operator's probabilistic cognitive state — neither override nor compression — preserving both authority and variability.* This framework, like Principle 7, operates under the operational integrity constraints summarized in Section 4 and is currently a v.5 design-stage framework, not yet implemented in shipped MILO code. **Operational specification is forthcoming work.** Principles 7 and 8 are introduced here as architectural commitments; their operational specification — including the baseline-establishment window for Principle 7, the recalibration cadence under operator life-events (illness, role change, circadian variation), the dose-response of the precision perturbation in Principle 8, and the drift-control mechanism for the perturbation magnitude over time — is the subject of forthcoming work tied to the v.5 development program. The principles articulate the design target; the operational validation against measurable outcomes is empirical work that follows from the principles, not work that precedes them. ## 4. Operational Integrity as Architectural, Not Policy-Level The eight principles describe the design space of viable adaptive AI orchestration. The operator-layer principles in Sections 3.7 and 3.8 admit deployment patterns that, without operational integrity constraints, would risk surveillance, coercion, or productivity enforcement. The architecture proposed here requires that those constraints be *structural*, not merely policy-level — implemented as enforceable code-level constraints in deployment builds and bound to the architectural design specification. The eight integrity constraints — *no coercion ever*, *individual baseline only*, *no surveillance architecture*, *operator authority is the invariant*, *operational transparency*, *data sovereignty*, *override always available*, and *independent oversight* — must operate as enforceable safeguards, not promises. Deployment patterns that cannot satisfy all eight are outside the permitted use boundary of the architecture by design. ## 5. Implications and Discussion Taken together, the eight principles constrain the design space of viable adaptive AI orchestration more tightly than the field currently acknowledges. The first six establish that adaptive AI is bounded by physical, informational, control-theoretic, and statistical constraints that have been known for between sixty and one hundred and seventy years. The seventh and eighth extend the framework to the operator-cognitive performance layer in high-consequence industrial environments, where human decision context can become a material source of system variance — and where the architectural form of the intervention is precision-targeted rather than population-averaged, perturbation-based rather than override-based. The framework is consistent with, and complementary to, several prior contributions. Friston's Free Energy Principle [3] provides a unified explanation of self-organizing systems at a level above architectural design; the eight principles operate one level below, as architectural constraints. Beer's Viable System Model [4] applies cybernetic feedback to recursive viable systems, especially organizations; the eight principles apply comparable viability discipline at the software-orchestration scale. Thermodynamics-inspired AI work [5] shows how thermodynamic concepts can illuminate black-box AI behavior; the present framework treats entropy as architectural diagnostic. Antifragility [10] provides the payoff-distribution analysis; the present framework treats antifragility as an architectural property of the adaptive-learning loop bounded by operator-authority constraints. The synthesis here is intended to complement, not displace, those frameworks. The framework leaves substantive work to subsequent contributions on adjacent architectural concerns: the application of the entropy diagnostic to multi-source thermal capture for cryptographic seeding, the application of pre-execution gating to latency-aware authentication in industrial control environments, the architectural form of supervisory primacy in human-in-the-loop AI orchestration for high-consequence domains, and the synthesis of antifragility, viability, and resilience into a unified design ethos — each developed in related work by the author. ## 5.1 Limitations This is a perspective paper synthesizing eight principles. Five specific limitations bound the present contribution: (i) the mapping of each established law (Principles 1–6) to a specific orchestrator-level architectural choice is the author's contribution and is subject to further validation; alternative mappings are plausible and not surveyed here; (ii) the relationship of Ashby's Law of Requisite Variety [6] to a fleet of specialist agents is a strong-form analogy rather than a derived result; (iii) Principle 6 (Power-Law Distribution) is an empirical regularity rather than a derived law in the strict sense, as noted explicitly in §3.6; (iv) Principles 7 and 8 — *Individual-Baseline Variance Modeling* and *Precision Perturbation Without Variance Compression* — are original frameworks pending empirical validation and are explicitly flagged as design-stage in §3.7 and §3.8 (their operational specification, including baseline-establishment windows and dose-response of the perturbation, is forthcoming work); (v) the synthesis does not claim a unified theory of intelligence and is explicitly distinguished from Friston's Free Energy Principle [3] in this respect. ## 6. Conclusion This paper has identified eight structural principles for adaptive AI architecture. Six are established physical and informational laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer. The principles operate as design-time constraints on architectural choices, not as a unified theory of intelligence. They constrain the design space of viable adaptive AI orchestration more tightly than current field discourse acknowledges. The contribution is at the level of engineering design — what an adaptive AI orchestration system must do architecturally to satisfy the constraints — and is illustrated using MILO, the author's working implementation [1], submitted under the U.S. Department of Energy's Genesis Mission [2]. The principles are intended to be falsifiable, applicable, and consistent with the broader literature on adaptive systems, cybernetics, and the thermodynamics of intelligence. --- ## Data Availability All architectural materials, source manuscripts, the reference implementation, and accompanying figures are openly available at https://github.com/jmontano1/milo-architecture and permanently archived at Zenodo (DOI: [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025)). No private datasets are referenced; the architectural framework itself is the subject of this paper. Patent rights for the underlying MILO software architecture are reserved; the ~MILO trademark is held under USPTO Serial No. 99706004 (intent-to-use, Class 009). ## References [1] J. E. Flores Montano, *MILO (Modular Intelligent Learning Orchestrator)*, JM Automated Solutions. Patent pending. Submitted under the U.S. Department of Energy Genesis Mission, 2026. [2] U.S. Department of Energy, "The Genesis Mission: Transforming Science and Energy with AI," Office of the Under Secretary for Science, Executive Order 14363, November 2025. [Online]. Available: https://www.energy.gov/genesis [3] K. Friston, "The free-energy principle: a unified brain theory?" *Nature Reviews Neuroscience*, vol. 11, no. 2, pp. 127–138, 2010. doi:10.1038/nrn2787 [4] S. Beer, *Brain of the Firm*, 2nd ed. Chichester, UK: Wiley, 1981. [5] S. Mehdi and P. Tiwary, "Thermodynamics-inspired explanations of artificial intelligence," *Nature Communications*, vol. 15, art. 7859, 2024. doi:10.1038/s41467-024-51970-x [6] W. R. Ashby, *An Introduction to Cybernetics*. London, UK: Chapman & Hall, 1956. [7] C. E. Shannon, "A Mathematical Theory of Communication," *Bell System Technical Journal*, vol. 27, no. 3, pp. 379–423, July 1948. [8] A. M. Lyapunov, *The General Problem of the Stability of Motion* (English translation, 1992 reprint of 1892 thesis). London, UK: Taylor & Francis, 1992. [9] A. Clauset, C. R. Shalizi, and M. E. J. Newman, "Power-law distributions in empirical data," *SIAM Review*, vol. 51, no. 4, pp. 661–703, 2009. doi:10.1137/070710111 [10] N. N. Taleb, *Antifragile: Things That Gain from Disorder*. New York, NY: Random House, 2012. [11] R. Parasuraman, T. B. Sheridan, and C. D. Wickens, "A model for types and levels of human interaction with automation," *IEEE Transactions on Systems, Man, and Cybernetics — Part A: Systems and Humans*, vol. 30, no. 3, pp. 286–297, May 2000. doi:10.1109/3468.844354 [12] E. Hollnagel, *Cognitive Reliability and Error Analysis Method (CREAM)*. Oxford, UK: Elsevier, 1998. [13] J. Reason, *Human Error*. Cambridge, UK: Cambridge University Press, 1990. [14] International Atomic Energy Agency, *INSAG-7: The Chernobyl Accident — Updating of INSAG-1*, Safety Series No. 75-INSAG-7. Vienna, Austria: IAEA, 1992. --- ## About the author Jorge Enrique Flores Montano (ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418); jmontano@jmautomated.com) is the founder of JM Automated Solutions and the inventor of MILO. A full biography is maintained at [https://www.milo-usa.com/jorge-enrique-flores-montano](https://www.milo-usa.com/jorge-enrique-flores-montano). ## Conflict of Interest and Funding Disclosure The author is the inventor of MILO (patent pending) and the founder of JM Automated Solutions. The eight structural principles articulated in this paper, including the two original frameworks proposed in Sections 3.7 and 3.8, are a contribution from a working development program in which the author retains sole authorship and inventive interest. No external funding was received for the preparation of this manuscript. The author retains all rights to MILO and to the original frameworks introduced herein. ## Appendix A — About MILO MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture organized into discrete, single-responsibility subsystems under a strict separation-of-concerns discipline. An audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, producing an append-only audit trail that survives arbitrary process termination. The architecture is designed for *viability* — operational continuity under non-stationary conditions — rather than for prediction accuracy against an expected future. ### Eight structural principles Six are established physical, informational, control-theoretic, and statistical laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems. 1. **Second Law of Thermodynamics** — entropy treated as an architectural diagnostic signal, not a fault to be suppressed. 2. **Ashby's Law of Requisite Variety** — a regulator must possess variety at least equal to the system it regulates; implemented as a fleet of specialist agents matching the operational domain. 3. **Shannon Information Theory** — variance reduction occurs at the signal-carrier level, not redundantly at each consumer. 4. **Principle of Least Action — Single-Target Dispatch** — every command has one explicit target; no implicit resolvers, no opaque dispatchers. 5. **Lyapunov-Style Bounded Response** — every adaptive subsystem admits an explicit halt-and-resume pathway; adaptation that drifts unboundedly is failure, not learning. 6. **Power-Law Distribution Architecture** — engineered for the 99th-percentile event, not the median. 7. **Individual-Baseline Variance Modeling** *(original framework)* — operator-layer interventions calibrated against the individual's own established performance baseline, never a population norm. Design-stage; pending empirical validation. 8. **Precision Perturbation Without Variance Compression** *(original framework)* — operator-layer interventions shift probability mass toward high-reliability decision outputs while preserving operator authority and the variability that *is* the operator's adaptive intelligence. Design-stage; pending empirical validation. ### Eight operational integrity constraints Architectural commitments designed to be implemented as enforceable safeguards in deployment builds — not as runtime policy. Disabling any constraint should require rebuilding from source, not toggling a flag. 1. **No coercion, ever** — the system issues recommendations, never compels. 2. **Individual baseline only** — measurements against the operator's own baseline; never against a population norm or productivity target. 3. **No surveillance architecture** — performance-support tool, not a monitoring infrastructure. 4. **Operator authority is the invariant** — the system expands effective decision options; it never narrows or preempts them. 5. **Operational transparency** — every recommendation includes a plain-language explanation. 6. **Data sovereignty** — operator-layer data belongs to the institutional program under documented data governance. 7. **Override always available** — overrides are logged for audit but never used for adverse personnel action. 8. **Independent oversight** — operator-layer deployments require institutional ethics-board review, published consent frameworks, and periodic third-party audits. ### Unifying principle > *MILO does not predict the future. It remains viable in any future.* The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle. ### Trademark, patent, and submission status - **Mark.** *~MILO™* — U.S. Patent and Trademark Office Serial No. 99706004; filed March 16, 2026; intent-to-use; International Class 009 (downloadable AI software). The leading tilde disambiguates from senior MILO marks held by unrelated owners in different International Classes. - **Patent.** Patent application pending for the underlying software architecture. Implementation may require a patent license once issued; nothing in this document or its CC BY 4.0 license on the manuscript text grants any patent license. - **Federal submission.** Submitted to the U.S. Department of Energy under the *Genesis Mission* (Executive Order 14363, November 2025); currently under review. No acceptance or grant outcome is claimed. - **Concept DOI.** [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025) — Zenodo, persistent across versions. - **Public reference.** [https://github.com/jmontano1/milo-architecture](https://github.com/jmontano1/milo-architecture). - **Author contact.** Jorge Enrique Flores Montano · jmontano@jmautomated.com · ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418). # Article 05: Adaptive Resilience --- title: "Adaptive Resilience: Why AI Systems Must Remain Viable in Any Future" subtitle: "Viability as an Architectural Discipline for Adaptive AI Orchestration in High-Consequence Environments" author: "Jorge Enrique Flores Montano" author_aliases: ["Jorge Flores Montano", "Jorge Montano", "Jorge E. Flores Montano", "J. E. Flores Montano"] affiliation: "JM Automated Solutions" date: 2026-05-11 description: "Viability as an architectural discipline for adaptive AI orchestration in high-consequence environments. Synthesizes Beer's Viable System Model, Hollnagel's resilience engineering, and Taleb's antifragility into a concrete engineering discipline for AI systems that must remain operational under unknown futures rather than optimize for predicted ones." keywords: - MILO - Modular Intelligent Learning Orchestrator - Jorge Flores Montano - Jorge Montano - Jorge Enrique Flores Montano - JM Automated Solutions - adaptive resilience - AI viability - antifragility - resilience engineering - Beer Viable System Model - Hollnagel four cornerstones - Taleb antifragile - distribution shift - AI orchestration - high-consequence AI - DOE Genesis Mission - patent pending - adaptive AI architecture - critical infrastructure - U.S. national interest tags: - milo - adaptive-resilience - ai-viability - antifragility - resilience-engineering - beer-vsm - hollnagel - taleb - jorge-flores-montano - jm-automated-solutions - doe-genesis-mission - patent-pending - critical-infrastructure - ai-orchestration article_number: 5 series_name: "MILO Architectural Series" series_total: 5 canonical_url: "https://www.milo-usa.com/articles/05-adaptive-resilience" trademark: "~MILO™ is a trademark of Jorge Enrique Flores Montano (USPTO Serial No. 99706004)" patent_status: "Patent Pending" copyright: "© 2026 Jorge Enrique Flores Montano / JM Automated Solutions" --- # Adaptive Resilience: Why AI Systems Must Remain Viable in Any Future **Subtitle:** Viability as an Architectural Discipline for Adaptive AI Orchestration in High-Consequence Environments **Author:** Jorge Enrique Flores Montano · Founder, JM Automated Solutions **~MILO™** — Modular Intelligent Learning Orchestrator (patent pending) **Publication date:** May 2026 --- ## Abstract Predictive optimization has reached structural limits as the design criterion for adaptive AI systems in high-consequence environments. Systems trained to maximize accuracy against expected future distributions fail under distribution shift, and the failure is not graceful: prediction-optimized systems collapse where the prediction was wrong. This paper argues that the next generation of adaptive AI orchestration must be designed for *viability* rather than for prediction accuracy — engineered to remain operational across futures that include the unforeseen, the rare, and the actively adversarial. The argument synthesizes three established lineages: Beer's Viable System Model [1], Hollnagel's resilience engineering [2], and Taleb's antifragility [3]. The contribution of this paper is not to restate those frameworks but to articulate viability as a concrete adaptive-AI orchestration discipline: an architecture in which audit-first command flow, modular subsystem construction with strict separation of concerns, bounded recovery pathways, tail-event preparation, and preserved operator authority together produce a system that does not require accurate prediction to remain useful. The discipline is illustrated using MILO, a patent-pending adaptive AI orchestrator [4] submitted to the U.S. Department of Energy under the Genesis Mission [5]. The unifying principle is stated plainly: *MILO does not predict the future. It remains viable in any future.* **Keywords:** adaptive AI, viability, resilience engineering, antifragility, distribution shift, AI orchestration, high-consequence systems, human-in-the-loop. **Highlights.** - Articulates *viability* as a concrete adaptive-AI orchestration discipline, distinct from prediction accuracy as a design criterion for high-consequence environments. - Synthesizes three established lineages — Beer's Viable System Model, Hollnagel's resilience engineering, and Taleb's antifragility — into a coherent design discipline operationalized through six mechanisms (M1–M6). - Frames viability as a falsifiable design target: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level fails the principle. - Bounds antifragility-applied-to-the-system from antifragility-applied-to-operators through eight non-negotiable operational integrity constraints. **Index Terms:** adaptive AI, viability, resilience engineering, antifragility, distribution shift, AI orchestration, high-consequence systems, Beer Viable System Model, Hollnagel four cornerstones, Taleb antifragile, non-stationarity, critical infrastructure. **Plain Language Summary.** Most AI systems today are designed to make accurate predictions about the future based on past data — and they fail, often catastrophically, when the future stops resembling the past. In critical-infrastructure environments (power grids, manufacturing lines, nuclear facilities, autonomous robotics, satellite operations), an AI system whose usefulness depends on accurate prediction is a brittle system. This paper argues that the next generation of AI orchestration for high-consequence environments must be designed for *viability* — the capacity to remain operational, auditable, and human-controllable under conditions the system was not trained to expect — rather than for prediction accuracy. The principle synthesizes Beer's cybernetic viability, Hollnagel's resilience engineering, and Taleb's antifragility into a concrete engineering discipline. **Relevance to U.S. National Interest.** AI systems deployed in U.S. critical-infrastructure environments — the deployment context identified by the DOE Genesis Mission — face operational futures that include adversarial action, climate-driven environmental shifts, supply-chain disruption, and unforeseen sociotechnical failures. AI orchestrators whose viability is contingent on prediction accuracy are structurally unsuited for those environments. The discipline articulated here is intended to make U.S. critical-infrastructure AI viable across the futures it will actually encounter. **Status of claims.** This paper synthesizes three established intellectual lineages — Beer's Viable System Model [1], Hollnagel's resilience engineering [2], and Taleb's antifragility [3] — into a *viability discipline* for adaptive AI orchestration. The lineages themselves are external references with extensive standing; the synthesis and the six mechanisms (M1–M6) articulated in §3 as a coherent design discipline whose explicit target is viability rather than prediction accuracy are the author's contribution. Mechanisms M1–M3 are foundational architectural patterns developed in companion architectural papers by the author [4]; M4–M6 are developed in greater technical depth in those companion papers, indexed at https://github.com/jmontano1/milo-architecture. Empirical validation of the viability discipline against actual non-stationary deployment scenarios is forthcoming work and is not claimed here. This manuscript is a preprint prior to peer review. **About MILO.** MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture for high-consequence critical-infrastructure environments. The full architectural reference — eight structural principles, eight operational integrity constraints, the unifying viability principle, and the trademark/patent status — is maintained as a single canonical document at https://github.com/jmontano1/milo-architecture (concept DOI: 10.5281/zenodo.20117025). Author contact: jmontano@jmautomated.com. --- ## 1. Introduction The dominant paradigm in machine-learning system design treats prediction accuracy against a held-out distribution as the central quality metric. Models are trained on past data, optimized for expected futures, deployed when accuracy crosses a threshold, and retrained when accuracy degrades. The paradigm has produced impressive systems in stationary or near-stationary domains. It has also produced a structural failure mode that is increasingly evident in operational deployments: when the deployment environment moves outside the training distribution, the system's behavior degrades without warning and often in ways that exceed the operational tolerance of the surrounding sociotechnical context. The failure is not new. Distribution shift in machine learning has been studied for two decades [6]. What is new is the consequence profile of the systems involved. An AI orchestration system embedded in an energy grid control room, a nuclear facility, a semiconductor fabrication line, or a defense command-and-control loop is no longer evaluable solely on prediction accuracy. It is evaluable on whether it remains *viable* — whether it preserves command-and-audit continuity, maintains recoverability after disturbance, supports human authority over consequential actions, and continues to produce useful operational behavior even when the future violates the assumptions under which the system was trained. The framing of viability as a design criterion is not original to this paper. Beer introduced the Viable System Model in 1972 [1] as a cybernetic framework for organizations that maintain identity under environmental change. Hollnagel's resilience engineering [2] formalized resilience as the capacity to *respond*, *monitor*, *learn*, and *anticipate*. Taleb's antifragility [3] formalized systems that gain rather than lose under bounded disorder. Recent work has extended antifragility into machine learning [7], proposing a dynamic-regret-based formalism for systems that improve under non-stationarity. The contribution of the present paper is narrower and more practical. It is the application of viability, resilience, and antifragility as a concrete *adaptive-AI orchestration discipline* — a set of mechanisms an AI orchestration system must implement architecturally to remain viable in operational deployment under high-consequence conditions. The discipline is engineering-level rather than theoretical, and it is illustrated using MILO [4], the author's working implementation submitted under the U.S. Department of Energy's Genesis Mission [5]. ## 2. Background and Related Work The argument builds on four lineages whose contributions are summarized here, named, and then differentiated from the present contribution. **Beer's Viable System Model** [1] specifies the minimum internal anatomy any organization needs to remain viable in a changing environment: a system of operations (S1), a coordination layer (S2), a control layer (S3), an intelligence/environment-scanning layer (S4), and an identity/policy layer (S5). The VSM is recursive — every viable system is composed of viable subsystems — and the framework has been applied to organizations, decentralized systems [8], and increasingly to autonomous AI architectures. The present paper is explicitly indebted to Beer. The differentiation is that the VSM is a cybernetic framework for any viable system; the discipline articulated here is the specific application of viable-system thinking to adaptive AI orchestration at the software-orchestration scale, with concrete mechanisms (modular organs, audit-first command flow, bounded reflexes) that operationalize the framework in a deployable system. **Hollnagel's resilience engineering** [2] formalized resilience as four capacities: the ability to *respond* (knowing what to do when something goes wrong), the ability to *monitor* (knowing what to look for), the ability to *learn* (knowing what has happened), and the ability to *anticipate* (knowing what to expect). The Resilience Analysis Grid (RAG) operationalizes the four capacities for assessment of complex sociotechnical systems. The present paper adopts Hollnagel's four capacities as architectural requirements for an adaptive AI orchestrator. The differentiation is at the level of architectural mechanism: each of the four capacities is mapped to a specific class of subsystem in the orchestrator (reflex response, monitoring organ, audit-driven learning, anticipatory pre-execution gating). **Taleb's antifragility** [3] formalized systems that *gain* from stressors, volatility, and bounded disorder — distinct from robust systems, which merely survive. The formal substrate is the inverted Jensen inequality: convex payoff functions under noisy inputs produce positive expected returns. Applied to engineered systems, antifragility is the design property by which controlled exposure to operational variance strengthens rather than degrades the system. The present paper adopts antifragility as an architectural property of the adaptive-learning loop only — a system that learns from reviewed operational outcomes and improves its thresholds and recommendations over time. It explicitly does *not* extend antifragility into a claim that human operators inside the system should be deliberately stressed for adaptation; that application is bounded by the operational integrity constraints described in Section 5. **Recent ML-antifragility work** [7] proposes a dynamic-regret-based formalism for machine learning systems that improve under non-stationarity. The framework operates at the level of algorithmic regret and theoretical ML guarantees. The present paper operates at the orchestration level — system-of-systems composition — and treats antifragility as an architectural property of the orchestrator's reviewed-outcome learning loop rather than as an algorithmic property of any individual model. Standards and regulatory context anchors the discussion in operational reality. NIST SP 800-82r3 [9] specifies operational technology security requirements, prioritizing availability, integrity, and safety. NIST AI 100-1 (AI RMF 1.0) [10], particularly Appendix C on AI Risk Management and Human-AI Interaction, addresses the governance dimensions of human-AI teaming in operational environments. These standards anchor the discussion in real deployment context but are used here for design-context grounding, not as compliance claims. ## 3. Viability as an Orchestration Discipline Adaptive AI orchestrators built for viability rather than prediction accuracy share six architectural mechanisms. Each mechanism corresponds to a specific failure mode of prediction-optimized systems. Several of these mechanisms — notably M6 (preserved operator authority) and M4 (tail-event preparation) — are developed in greater technical depth in companion architectural papers by the author and are indexed at the public reference https://github.com/jmontano1/milo-architecture; the contribution of the present paper is the unifying frame in which all six operate together as a coherent viability discipline whose explicit target is operational resilience under non-stationary conditions. [FIGURE_1] **M1 — Audit-first command flow.** Every command issued by the orchestrator persists to a durable, append-only audit log before it dispatches to its target [4]. If the process terminates between dispatch and execution, replay reconstructs exact state. Prediction-optimized systems often lack this property; their decision trace is reconstructed from in-memory state and is lost when memory is lost. The architectural pattern *persist-before-deliver* — every visible state is backed by a persisted event — operates as the mechanism that makes the orchestrator's behavior auditable across futures, including the future in which the process crashed. **M2 — Modular subsystem architecture with strict separation of concerns.** The orchestrator is organized into discrete, single-responsibility subsystems under a single-owner rule [4]: every source file lives in exactly one subsystem. The pattern admits component-level replacement without systemic collapse. The architectural consequence is that adaptation, repair, or addition occurs at the subsystem level; the rest of the system continues to operate. Prediction-optimized monolithic models cannot offer this — a degraded behavior often requires full retraining and full redeployment. **M3 — Bounded recovery pathways.** Every adaptive subsystem admits an explicit halt-and-resume pathway dispatched through the same audited command bus as any other command, with end-to-end audit entries from critical signal through reflex through halt-executor [4]. The pathway implements the bounded-response property characteristic of Lyapunov-style stability: when the subsystem departs its equilibrium zone, the recovery path is architectural, not improvised. Adaptation that drifts unboundedly is not learning — it is failure. **M4 — Tail-event preparation.** Empirical statistics in complex systems show that consequence profiles are heavy-tailed: the 99th-percentile event dominates the total loss [11]. Viable orchestrators implement rolling-window degradation detection, periodic self-monitoring on a bounded cadence (rather than operator-triggered checks), and bounded reporting under tail events. In MILO, an integrity-monitoring subsystem runs a periodic self-monitoring scheduler on a bounded cadence with reflex auto-declare on findings; the architecture is engineered for the 99th-percentile event, not the median. **M5 — Reviewed-outcome learning.** Adaptive learning operates on reviewed operational outcomes — outcomes for which the audit trail is intact and the human-authoritative review has been recorded. The system improves its thresholds, recommendations, and reflex parameters based on outcomes that have been audited, not on raw operational data. This is the architectural form of antifragility within the learning loop: the system *gains* from bounded operational variance under the explicit precondition that the variance is reviewed and the gain is supervised. **M6 — Preserved operator authority.** Every consequential action passes through an explicit pre-execution gate that admits an operator override at any time, with the override logged for audit but never used to trigger adverse personnel or operational consequences [4]. The architectural pattern named *operator authority is the invariant* operates as the safeguard that prevents the orchestrator from degrading from useful-supplement to opaque-decision-maker as the deployment matures. Prediction-optimized systems often lack a structural override; the override becomes a policy promise rather than an architectural property. Taken together, the six mechanisms operationalize viability as an architectural discipline rather than as a marketing claim. None of the six requires accurate prediction of the future. Each contributes to the system's capacity to remain useful in a future the system was not trained to expect. ## 3.1 Distinction from Prior Orchestration Work Orchestration as an engineering category is long-established. Beer's Viable System Model dates to 1972 [1]; service orchestration in distributed systems is decades old; workflow orchestration in industrial automation, business process management, and cloud-native computing are mature fields each with their own conventions and tools. The contribution of this paper is not orchestration itself. It is the *viability discipline* applied to adaptive AI orchestration in high-consequence operational environments where the orchestrator must remain operational, auditable, and human-controllable under operational futures the orchestrator was not trained for. The discipline is specifically the six architectural mechanisms (M1 through M6) operating together in service of an explicit design target — *viability*, not prediction accuracy — under deployment contexts (advanced manufacturing, grid reliability, human-in-the-loop AI for critical infrastructure) where the consequence profile of failure is severe and the operational futures are non-stationary. The novelty of the present paper relative to prior orchestration work is the architectural application of viability discipline to this specific class of deployment, not the orchestration substrate itself. ## 4. The Unifying Operational Principle The discipline above is summarized by a single operational principle, stated as the unifying claim of the framework submitted by the author under the DOE Genesis Mission [5]: > *MILO does not predict the future. It remains viable in any future.* The principle requires a precise distinction. MILO is an *orchestrator* — a system that routes commands among subsystems (human operator → command bus → target organ), persists each command before dispatch, runs reflex predicates before fanout, and preserves operator authority over consequential actions. The orchestrator does not itself produce predictive forecasts of operational futures. The AI models invoked through the orchestrator may produce predictions, but the orchestrator's viability does not depend on those predictions being accurate; it depends on the orchestrator's architectural properties — audit completeness, bounded recovery, modular organ structure, tail-event preparation, reviewed learning, preserved operator authority — holding under any operational future the orchestrator encounters. The principle is not a prediction claim. It is a design target: avoid single-point collapse, preserve command-and-audit continuity, maintain recoverability after disturbance, improve from reviewed events, and preserve operator authority across the system's deployment lifetime. The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle and is therefore not viable in the sense developed here. The v.5 extension submitted under the Genesis Mission adds a parallel principle for the operator-cognitive performance layer of high-consequence systems: the same architectural discipline that produces system-level viability is extended to the human operators inside the system — *not* by stressing operators for adaptation (the inverse of antifragility-applied-to-people), but by supporting operators against cognitive load, fatigue, and task-state misalignment under the eight operational integrity constraints (consent, individual baseline, no surveillance, operator authority, transparency, data sovereignty, override, independent oversight) [5]. Section 5 addresses the governance dimensions of this extension explicitly. ## 5. Governance: Antifragility Does Not Mean Stress Dosing Operators A framework that adopts Taleb's antifragility as an architectural property in an industrial-AI context must be explicit about the boundary between system-level antifragility and operator-level stress exposure. The boundary is non-negotiable in the framework presented here. Antifragility applies to the orchestrator's reviewed-outcome learning loop. It does *not* apply to the human operators embedded in the system. Operator-facing components of the orchestrator operate under eight non-negotiable operational integrity constraints [5]: (1) *No coercion, ever* — the system issues recommendations, never compels. (2) *Individual baseline only* — cognitive-state-aware decision support measures against the operator's own established performance baseline, never against a population norm, government standard, or employer productivity target. (3) *No surveillance architecture* — the system is designed as a performance-support tool, not a monitoring infrastructure. (4) *Operator authority is the invariant* — the system expands effective decision options; it never narrows or preempts them. (5) *Operational transparency* — every recommendation includes a plain-language explanation of what signal was detected and what options the operator has. (6) *Data sovereignty* — operator-layer performance data belongs to the institutional program under documented data governance. (7) *Override always available* — operators can override any recommendation at any time, with overrides logged for audit but never used for adverse personnel action. (8) *Independent oversight* — operator-layer deployments require institutional ethics board review, published consent frameworks, and periodic third-party audits. These constraints are specified as architectural commitments designed to be implemented as enforceable safeguards in deployment builds, not as policy-level promises. The architectural target is structural enforcement — code-level invariants bound to the design specification — so that violations should require rebuilding from source rather than toggling a runtime flag. The framework's claim is not that operators should be made antifragile by deliberate exposure to stress; it is that the *system* should be made antifragile by reviewed adaptation, while the operators inside the system are supported, not optimized. ## 6. Implications and Discussion The discipline of viability as an adaptive AI orchestration property has implications for the design, evaluation, and deployment of AI systems in high-consequence environments. For *design*, it implies that the architectural choices made before training — the command bus, the audit substrate, the modular subsystem boundaries, the reflex layer, the operator override path — bound the system's eventual viability more tightly than any subsequent algorithmic improvement can recover. A system designed for prediction-accuracy-only cannot be retrofitted into a viability-grade orchestrator; the substrate must be present from the beginning. For *evaluation*, it implies that prediction accuracy is necessary but insufficient. An adaptive AI orchestration system must be evaluated on its mean-time-to-recovery after disturbance, its audit-trail completeness, its tail-event preparedness, its operator-override exercise frequency under operational conditions, and its capacity to improve from reviewed outcomes — none of which are visible in a held-out accuracy metric. Operational measurement requires definitions; this paper proposes the *evaluation axes* rather than the operational metrics themselves, with each axis to be defined per deployment context. Candidate operational metrics in the framework's supporting documentation — including operator-attributable fault initiation rate, recoverable loss minutes, and decision-quality degradation against individual baseline — are specified with explicit numerator, denominator, observation window, attribution rule, and baseline comparison, and are not invoked here without those definitions. For *deployment*, it implies that high-consequence environments — energy grid control rooms, nuclear facilities, advanced manufacturing lines, autonomous robotics under human supervision, satellite and space operations, national laboratory experimental campaigns — should not deploy adaptive AI systems that lack the six architectural mechanisms described in Section 3. The DOE Genesis Mission's emphasis on AI in advanced manufacturing, grid reliability, and human-in-the-loop systems [5] is precisely the deployment context in which viability-discipline architecture, rather than prediction-optimization, is operationally appropriate. ## 6.1 Limitations This paper proposes a viability discipline; it does not present an empirical evaluation. Four specific limitations bound the present contribution: (i) the six mechanisms (M1–M6) are articulated at the architectural level; their per-mechanism operational metrics (mean-time-to-recovery after disturbance, audit-trail completeness rate, tail-event preparedness frequency, reviewed-outcome adaptation rate, override exercise rate) are specified as *evaluation axes* in §6 but are not measured against any deployed instance in this paper; (ii) the synthesis of Beer [1], Hollnagel [2], and Taleb [3] is the author's reading of those lineages and is not endorsed by those authors; alternative syntheses are plausible; (iii) the operator-cognitive performance layer (referenced via the v.5 extension in §4) is design-stage and bounded by the governance constraints in §5, not by shipped operational practice; (iv) the submission of MILO under the DOE Genesis Mission [5] is under review; no acceptance or grant outcome is claimed. Empirical validation of the viability discipline against actual non-stationary deployment scenarios is forthcoming work. ## 7. Conclusion This paper has argued that adaptive AI systems in high-consequence environments must be designed for viability rather than for prediction accuracy. The argument is built on Beer's Viable System Model [1], Hollnagel's resilience engineering [2], and Taleb's antifragility [3], with adaptations to the specifics of AI orchestration: audit-first command flow, modular subsystem construction with strict separation of concerns, bounded recovery, tail-event preparation, reviewed-outcome learning, and preserved operator authority. The discipline is operationalized in MILO [4], submitted under the U.S. Department of Energy's Genesis Mission [5]. The unifying principle — *MILO does not predict the future; it remains viable in any future* — is a design target, not a prediction claim. Related architectural directions by the author — multi-source cryptographic entropy sourcing, latency-aware authentication in industrial control, supervisory primacy for human-in-the-loop AI orchestration, and the structural principles of adaptive AI architecture — each inherit the viability discipline as their substrate. --- ## Data Availability All architectural materials, source manuscripts, the reference implementation, and accompanying figures are openly available at https://github.com/jmontano1/milo-architecture and permanently archived at Zenodo (DOI: [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025)). No private datasets are referenced; the architectural framework itself is the subject of this paper. Patent rights for the underlying MILO software architecture are reserved; the ~MILO trademark is held under USPTO Serial No. 99706004 (intent-to-use, Class 009). ## References [1] S. Beer, *Brain of the Firm*, 2nd ed. Chichester, UK: Wiley, 1981. [2] E. Hollnagel, D. D. Woods, and N. Leveson, Eds., *Resilience Engineering: Concepts and Precepts*. Aldershot, UK: Ashgate, 2006. [3] N. N. Taleb, *Antifragile: Things That Gain from Disorder*. New York, NY: Random House, 2012. [4] J. E. Flores Montano, *MILO (Modular Intelligent Learning Orchestrator)*, JM Automated Solutions. Patent pending. Submitted under the U.S. Department of Energy Genesis Mission, 2026. [5] U.S. Department of Energy, "The Genesis Mission: Transforming Science and Energy with AI," Office of the Under Secretary for Science, Executive Order 14363, November 2025. [Online]. Available: https://www.energy.gov/genesis [6] J. Quiñonero-Candela, M. Sugiyama, A. Schwaighofer, and N. D. Lawrence, Eds., *Dataset Shift in Machine Learning*. Cambridge, MA: MIT Press, 2009. [7] M. Jin, "Preparing for Black Swans: The Antifragility Imperative for Machine Learning," *arXiv preprint* arXiv:2405.11397, May 2024. [8] K. Nabben and M. Zargham, "Applying Stafford Beer's Viable System Model to Decentralized Organization," *BlockScience*, Apr. 2022. [Online]. Available: https://blog.block.science/applying-stafford-beers-viable-system-model-to-decentralized-organization/ [9] National Institute of Standards and Technology, *Guide to Operational Technology (OT) Security*, NIST SP 800-82r3, Sep. 2023. doi:10.6028/NIST.SP.800-82r3 [10] E. Tabassi, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1, National Institute of Standards and Technology, Jan. 2023, Appendix C: AI Risk Management and Human-AI Interaction. doi:10.6028/NIST.AI.100-1 [11] A. Clauset, C. R. Shalizi, and M. E. J. Newman, "Power-law distributions in empirical data," *SIAM Review*, vol. 51, no. 4, pp. 661–703, 2009. doi:10.1137/070710111 --- ## About the author Jorge Enrique Flores Montano (ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418); jmontano@jmautomated.com) is the founder of JM Automated Solutions and the inventor of MILO. A full biography is maintained at [https://www.milo-usa.com/jorge-enrique-flores-montano](https://www.milo-usa.com/jorge-enrique-flores-montano). ## Conflict of Interest and Funding Disclosure The author is the inventor of MILO (patent pending) and the founder of JM Automated Solutions. The discipline proposed in this paper is a contribution from a working development program in which the author retains sole authorship and inventive interest. No external funding was received for the preparation of this manuscript. The author retains all rights to MILO and to the discipline articulated herein. ## Appendix A — About MILO MILO (Modular Intelligent Learning Orchestrator) is a patent-pending adaptive AI orchestration architecture organized into discrete, single-responsibility subsystems under a strict separation-of-concerns discipline. An audit-first command-and-signal substrate persists every command before dispatch and every signal before fanout, producing an append-only audit trail that survives arbitrary process termination. The architecture is designed for *viability* — operational continuity under non-stationary conditions — rather than for prediction accuracy against an expected future. ### Eight structural principles Six are established physical, informational, control-theoretic, and statistical laws applied as architectural design constraints; two are original frameworks proposed by the author for the operator-cognitive performance layer of high-consequence systems. 1. **Second Law of Thermodynamics** — entropy treated as an architectural diagnostic signal, not a fault to be suppressed. 2. **Ashby's Law of Requisite Variety** — a regulator must possess variety at least equal to the system it regulates; implemented as a fleet of specialist agents matching the operational domain. 3. **Shannon Information Theory** — variance reduction occurs at the signal-carrier level, not redundantly at each consumer. 4. **Principle of Least Action — Single-Target Dispatch** — every command has one explicit target; no implicit resolvers, no opaque dispatchers. 5. **Lyapunov-Style Bounded Response** — every adaptive subsystem admits an explicit halt-and-resume pathway; adaptation that drifts unboundedly is failure, not learning. 6. **Power-Law Distribution Architecture** — engineered for the 99th-percentile event, not the median. 7. **Individual-Baseline Variance Modeling** *(original framework)* — operator-layer interventions calibrated against the individual's own established performance baseline, never a population norm. Design-stage; pending empirical validation. 8. **Precision Perturbation Without Variance Compression** *(original framework)* — operator-layer interventions shift probability mass toward high-reliability decision outputs while preserving operator authority and the variability that *is* the operator's adaptive intelligence. Design-stage; pending empirical validation. ### Eight operational integrity constraints Architectural commitments designed to be implemented as enforceable safeguards in deployment builds — not as runtime policy. Disabling any constraint should require rebuilding from source, not toggling a flag. 1. **No coercion, ever** — the system issues recommendations, never compels. 2. **Individual baseline only** — measurements against the operator's own baseline; never against a population norm or productivity target. 3. **No surveillance architecture** — performance-support tool, not a monitoring infrastructure. 4. **Operator authority is the invariant** — the system expands effective decision options; it never narrows or preempts them. 5. **Operational transparency** — every recommendation includes a plain-language explanation. 6. **Data sovereignty** — operator-layer data belongs to the institutional program under documented data governance. 7. **Override always available** — overrides are logged for audit but never used for adverse personnel action. 8. **Independent oversight** — operator-layer deployments require institutional ethics-board review, published consent frameworks, and periodic third-party audits. ### Unifying principle > *MILO does not predict the future. It remains viable in any future.* The principle is falsifiable: a system whose audit trail is incomplete, whose recovery is improvised, whose adaptation drifts unboundedly, or whose operator override is policy-level rather than architectural, fails the principle. ### Trademark, patent, and submission status - **Mark.** *~MILO™* — U.S. Patent and Trademark Office Serial No. 99706004; filed March 16, 2026; intent-to-use; International Class 009 (downloadable AI software). The leading tilde disambiguates from senior MILO marks held by unrelated owners in different International Classes. - **Patent.** Patent application pending for the underlying software architecture. Implementation may require a patent license once issued; nothing in this document or its CC BY 4.0 license on the manuscript text grants any patent license. - **Federal submission.** Submitted to the U.S. Department of Energy under the *Genesis Mission* (Executive Order 14363, November 2025); currently under review. No acceptance or grant outcome is claimed. - **Concept DOI.** [10.5281/zenodo.20117025](https://doi.org/10.5281/zenodo.20117025) — Zenodo, persistent across versions. - **Public reference.** [https://github.com/jmontano1/milo-architecture](https://github.com/jmontano1/milo-architecture). - **Author contact.** Jorge Enrique Flores Montano · jmontano@jmautomated.com · ORCID iD: [0009-0003-1859-8418](https://orcid.org/0009-0003-1859-8418).