# Machine-Executable Policy **Domain:** Austin Research / Concepts **Doc Type:** Corpus analysis **Source basis:** Supplied research cluster with linked references; see the [[wiki/Austin Research Evidence Map|evidence map]] for verification scope. **Machine-Executable Policy** represents handling or decision rules in a form software can evaluate and apply. The [[wiki/IC ITE|IC ITE]] data strategy provides a concrete institutional example through machine-interpretable conditions for access, sharing, and use. The mechanism joins data markings with requesting identities, relevant attributes, and an enforcement service. A rule becomes consequential when systems actually evaluate it on a request and record the result. Its originating authority remains distinct from the machinery applying it. The Austin succession reading concerns a reduced need for humans to mediate every routine transaction. Policy execution, policy authorship, and authority to change policy remain separate functions. ## Connected entries [[wiki/IC ITE|IC ITE]] · [[wiki/Unified Identity Attribute Set|Unified Identity Attribute Set]] · [[wiki/Attribute-Based Access Control|Attribute-Based Access Control]] · [[wiki/Trusted Data Format|Trusted Data Format]] · [[wiki/Algorithmic Governance|Algorithmic Governance]] · [[wiki/Digital Administrative Infrastructure|Digital Administrative Infrastructure]] · [[wiki/Intelligence Community Cloud Architecture|Intelligence Community Cloud Architecture]] ## Sources and corpus context - [[research/IC ITE - Intelligence Community Information Technology Enterprise|IC ITE - Intelligence Community Information Technology Enterprise]] - [[research/The Austin Executable Loop|The Austin Executable Loop — master document]] - [Intelligence Community Data Strategy 2017–2021](https://www.odni.gov/files/documents/CIO/Data-Strategy_2017-2021_Final.pdf) - [IC Technical Specification — Unified Identity Attribute Set](https://www.odni.gov/files/documents/CIO/ICEA/IC_Tech_Spec_Attributes_V2_Final_PUBLIC.pdf) - [Vision for the IC Information Environment — May 2024](https://www.odni.gov/files/documents/CIO/IC-IT-Roadmap-Vision-For-the-IC-Info-Environment-May2024.pdf) **Cluster:** [[wiki/Austin Executable Loop|Austin Executable Loop]] · [[wiki/Austin Research Evidence Map|Austin Research Evidence Map]] <!-- BEGIN AUSTIN SURVEILLANCE FIELD --> ## Agreements expressed through access controls The LEAP agreement assigns gateway control, security review, audit, and suspension to NCTCOG. The DHS LEIS briefing specifies the service and data-exchange layer. Together they identify where human-authored participation rules meet technical enforcement. The actual LEAP rule engine or attribute policy is not described by the reviewed documents, so it should not be assumed identical to IC ITE’s. Provider transitions raise a further question: which permissions, correction duties, and restrictions remain enforceable when the operator changes? **Follow:** [[wiki/Interlocal Information Sharing|Interlocal Information Sharing]] · [[wiki/LEAP Provider Transition|LEAP Provider Transition]] · [[wiki/DHS Law Enforcement Information Sharing Service|DHS Law Enforcement Information Sharing Service]] **Source:** [[research/The Austin Surveillance Field|The Austin Surveillance Field]]; [City of Austin — LEAP interlocal agreement, recitals and §§2–7](https://services.austintexas.gov/edims/document.cfm?id=176641); [DHS — Law Enforcement Information Sharing Service briefing, slides 4–16; existing MOUs on slide 15](https://info.publicintelligence.net/DHS-LEISS.pdf). <!-- END AUSTIN SURVEILLANCE FIELD -->