Building a Governance-First Pipeline for Government Software
If you lead IT for a state agency, a county court, or a public university, you have almost certainly been asked some version of this question in the last twelve months.
Can we use AI to write our software faster?
The honest answer is yes. The more important answer is: not without a governance model that a state auditor, a CJIS compliance officer, and your agency counsel would all sign off on.
At Estrada Consulting, we have spent the last two and a half decades delivering application development, data platforms, and enterprise architecture to California agencies and similar public-sector clients across the country. Over the last several months, I have been building and testing a methodology for applying AI-assisted code generation to regulated government software, specifically the kind of workload where CJIS Security Policy, NIST 800-53 zero-trust controls, and PII handling rules cannot be negotiated down.
This post walks through what we have learned, why we believe governance (not raw generation speed) is the real differentiator for SLED agencies, and what a disciplined pipeline actually looks like in practice.
Why “AI writes your code” is the wrong framing for government
Most of the AI coding conversation happening in the broader software industry right now is centered on developer productivity: faster feature delivery, fewer tickets, shorter sprints. That framing works reasonably well for a consumer app or an internal dashboard.
It breaks down almost immediately in a SLED environment, for three reasons.
- Compliance is not an afterthought. A court case intake service that accepts filings from external agencies must enforce CJIS encryption, authenticate every request against the state identity provider, mask personally identifiable information per policy, and produce an audit trail that survives a records request. Speed of code generation is not interesting if the generated code cannot be verified against those mandates.
- Accountability is specific and personal. When an IT architect signs off on an integration, a security validator approves an encryption approach, or a chief data officer accepts an interoperability mapping, those are not ceremonial steps. They are the record the agency will point to when something is questioned later. Any methodology that bypasses or obscures those approvals is a non-starter.
- Change is continuous. Policies shift. Canonical schemas get revised. New mandates come down from federal agencies. A system that was correctly built two years ago may need targeted reconstruction tomorrow, and the agency needs to know exactly which components are affected by a given policy change without re-reviewing the entire codebase.
These realities do not argue against using AI in government software delivery. They argue for using it inside a framework that treats governance as the primary design constraint.
What this looks like in practice
This governance-first approach is not theoretical. We are already applying these principles in active client engagements where compliance, auditability, and data integrity are non-negotiable.
Example: Cloud-native case management and compliance platform (Public Health / Judicial Integration)
In a recent engagement, we designed and delivered a cloud-native platform to manage client treatment workflows, HR compliance, and judicial reporting requirements. The system supports the full lifecycle of regulated case data, from intake through disposition, while enforcing strict controls around personally identifiable information (PII), access, and auditability.
Key characteristics of the solution included:
- Role-based access control and secure authentication aligned with least-privilege principles
- End-to-end audit trails for all data changes and workflow actions
- Configurable validation rules and workflows to enforce policy at the application layer
- Cloud-native architecture (Azure) designed for scalability, resilience, and secure data handling
- Integrated data pipelines to manage ingestion, transformation, and reporting with traceability
What is notable is not just the technology, but the structure: requirements were translated into explicit data, workflow, and policy definitions before implementation. This mirrors the same principle behind the IMHOTEP pipeline, formalizing intent first, then generating and validating implementation artifacts in a controlled, auditable way.
This is the direction we see across agencies: AI and automation are being introduced, but only within systems that can demonstrate control, traceability, and compliance from the ground up.
What has changed in the last 12–24 months
The conversation around AI in government software delivery has shifted significantly in a short period of time.
First, AI capabilities have moved from experimental to embedded. Tools such as natural language querying, automated reporting, and anomaly detection are now being integrated directly into enterprise data platforms. In multiple recent engagements, we have implemented AI-assisted features, such as forecasting models, anomaly detection, and natural language interfaces, on top of governed data environments rather than as standalone experiments.
Second, cloud-native architectures have become the default foundation for modernization. Agencies are no longer simply migrating systems; they are rebuilding them using scalable, modular patterns that support continuous integration, automated deployment, and policy-driven controls. This shift is essential for enabling AI safely, because it creates the infrastructure needed for repeatable validation and enforcement.
Third, expectations around governance have increased, not decreased. As AI accelerates development, agencies are placing greater emphasis on:
- Data lineage and traceability
- Policy enforcement at the system level
- Repeatable validation and testing processes
- Clear accountability for approvals and changes
In other words, AI is compressing the software development lifecycle, but it is also raising the bar for control. The agencies that are succeeding are not the ones generating code the fastest, but the ones that can prove, at any point in time, that their systems behave as intended and comply with policy.
This is the context in which a governance-first pipeline becomes not just useful, but necessary.
A disciplined pipeline, in plain language
The methodology we have been refining, internally referred to as the IMHOTEP pipeline, organizes AI-assisted software delivery into five sequential phases. Each phase has a specific owner, a specific deliverable, and a specific approval gate. Nothing advances to the next phase until the prior phase has been formally accepted.
View full-size infographic (opens in new tab) →
Phase 1: Canonical Semantic Model Definition. Before any code is generated, human experts define what the system must do using a formal vocabulary of thirteen entity types, including Project, Capability, Service, DataEntity, Policy, Validation, and seven additional core constructs. This produces a structured, machine-readable specification rather than a loose requirements document. The specification is version-controlled and traceable.
Phase 2: Architectural Blueprint and Formal Approval Gates. Authored as structured Markdown with YAML frontmatter, the blueprint (called a Structured Transaction Payload) becomes the machine-parseable definitive intent for the system. Before anything advances to code generation, named governance roles sign off: IT Architects approve the API definitions, Security Validators approve the encryption and authentication posture, and the Chief Data Officer and court auditors approve the interoperability mappings to the agency’s canonical schema. Only after these approval gates close does the blueprint reach the “Autonomous-Ready” level.
Phase 3: Semantic Normalization and Governance. The approved blueprint is mapped into a semantic graph and committed to a version-controlled artifact repository, establishing the authoritative architectural baseline. This is the handoff point where the formal specification becomes the single source of truth that every downstream artifact, code, tests, and deployment manifests, must trace back to.
Phase 4: Pipeline Integration and Testing. Deterministic test suites are generated to verify that the implementation strictly satisfies the policies captured in the specification. Tests are not generic quality checks; they are formal verifications mapped to specific policy identifiers. If the code does not satisfy a policy, the pipeline halts. This is the “Andon Cord” principle, borrowed from Toyota manufacturing: any worker, human or automated, can stop the line when something is wrong.
Phase 5: Deployment Readiness and Artifact Consolidation. Once the code satisfies all deterministic validations, it is packaged into containerized deployment artifacts, along with a bidirectional traceability graph that mathematically links every piece of generated code back to the specific requirement it satisfies. That traceability graph is what allows an auditor, months or years later, to ask “show me every line of code that implements CJIS encryption policy POL-CJIS-001” and receive a precise, verifiable answer.
Applying the pipeline to a court case intake service
To validate this methodology, we developed a proof-of-concept: a REST service that accepts court case filings, enforces Entra ID authentication, validates incoming payloads against the canonical court data schema, applies PII masking rules, and persists records with full audit metadata. The service was built in .NET/C#, containerized for local-first deployment, and evaluated against a deterministic test suite mapped directly to CJIS, NIST 800-53, and PII policy requirements.
What matters about the proof-of-concept is not the specific technology stack. What matters is that every design decision, every line of generated code, and every test case can be traced back to an approved requirement authored by a named human in a governance role. If a court auditor asks tomorrow why a particular field is masked, or why a particular endpoint rejects an unauthenticated request, the answer is not in a developer’s head. It is in the traceability graph.
Why this matters for California SLED agencies
California state, local, and education agencies operate under some of the most rigorous procurement and compliance frameworks in the country. CMAS, TDDC, and MSA procurement vehicles; state-level data governance mandates; agency-specific security policies layered on top of federal CJIS and NIST requirements; and a public records environment that demands defensible documentation of every technology decision.
In that environment, a consulting partner that can demonstrably produce software with:
- A formal, version-controlled specification signed off by named governance roles
- Deterministic test evidence mapped to specific compliance policies
- Bidirectional traceability from requirement to code to test to deployment artifact
- A documented escalation pathway when the automated pipeline encounters a conflict it cannot resolve
That kind of partner offers something materially different from one that simply delivers working code on a reasonable timeline. Working code is the baseline. Defensible, auditable, policy-traceable code is the deliverable that state agencies and their oversight bodies actually need.
Where we go from here
We are continuing to refine this methodology across additional government use cases, including data integration pipelines, legacy modernization efforts, and business intelligence workloads where source data carries compliance constraints. Our experience over the last twenty-five-plus years delivering for agencies like CA – Dept of Corrections and Rehabilitation, CA – Dept of Justice, CA – Dept of Managed Healthcare, CA – Dept of Technology, and WA Sound Transit has shaped how we think about governance, and this pipeline is a direct extension of that institutional discipline, applied to a new generation of tooling.
If you are an IT leader at a California SLED agency thinking through how to responsibly introduce AI-assisted development into your portfolio, or a program manager who needs to answer hard questions from auditors and stakeholders about how AI-generated software will be governed, we would welcome a conversation.