EXPERIENCE
Industrial AI Engineering
Experience building AI solutions for real industrial problems, backed by MLOps and LLMOps practice: versioned data, model lineage, evaluation and CI gates.
Public engineering lab · Industrial AI · Experiments, decisions & lessons learned
Industrial AI Engineering.
AI Systems Architecture & Autonomous Systems.
Exploring and engineering AI systems at the intersection of industrial applications, agentic architectures, cloud-native infrastructure and autonomous software engineering. I document experiments, architectural decisions, implementation details and lessons learned, focusing on what works, where systems fail, and which patterns can be applied to real industrial environments.
dark-gravity — experiment.log (illustrative)
$ gh issue create --label autonomous-mission
✔ mission signed (Ed25519 · NHI)
✔ plan rustant · spec-kit contract
✔ code zeroclaw · gVisor ≤ 30 MiB
✔ validate tests + SAST in sandbox
✔ review LLM-judge score 8.6 / 10
⏸ awaiting human approval…
$ - Experience
- Industrial AI Engineering
- Experimentation
- Agents & Autonomous Eng.
- Application
- Knowledge → Industry
- Public Repositories
- 60+
About Dr. Luis Galo Corzo
A long-running technical notebook
Ph.D. in Engineering with 15+ years in industrial systems and years of hands-on MLOps, LLMOps and enterprise AI work. This site is not a product pitch and does not claim that autonomous engineering is solved. It is a personal lab: I build, test, break and document ideas, then evaluate which architectural patterns are worth carrying into industrial contexts.
EXPERIMENTATION
AI Systems Architecture & Autonomous Engineering
Experiments with agents, autonomous software factories, orchestration, Kubernetes, security and knowledge systems.
APPLICATION
Engineering Knowledge into Industrial AI
Evaluating which architectural patterns are useful, which fail, and which deserve to be assessed for enterprise environments.
Engineering diary
Lab notebook: how experiments are documented
Every entry leaves a permanent trail: code, architectural decision, result and lesson. A failed experiment can be more valuable than a successful one if it exposes a real architectural problem.
EXPERIMENT
Run an autonomous mission on Kubernetes
Shows what really works.
ARCHITECTURAL DECISION
Hatchet vs. a custom state machine
Explains the technical reasoning.
DOCUMENTED FAILURE
An agent generates code that fails the tests
Shows learning and limits.
COMPARISON
gVisor vs. other isolation strategies
Makes the trade-offs visible.
EVOLUTION
How the architecture changes after 20 missions
Demonstrates accumulated learning.
INDUSTRIAL TRANSFER
Which orchestration pattern could suit enterprise systems
Connects the lab with industrial experience.
Every entry answers five questions
- What did I want to verify?
- Which architecture and configuration did I use?
- What actually happened?
- What did I learn and which limitations did I find?
- What would I do differently in the next experiment?
From lab to industry, without mixing environments
Learnings are kept in three clearly separated categories.
A · PERSONAL EXPERIMENT
Code, models, agents, orchestration, storage and deployments under my own control. Free to iterate.
B · REUSABLE PATTERN
The general lesson: state persistence, agent evaluation, permissions, traceability, recovery, context management.
C · ENTERPRISE APPLICATION
Assessed against real requirements, security and architecture constraints through the corresponding internal process.
No internal configurations, proprietary code, customer data, credentials, identifiable incidents or confidential architecture details are published here. A pattern that works in the lab is not assumed ready for production: the lab reduces uncertainty, enterprise adoption requires its own evaluation.
Autonomous engineering lab
Dark Gravity — a lab for autonomous engineering
The main project for experimenting with automating the development cycle: specification, planning, code generation, validation, isolation and delivery. It publishes architectural decisions, runs, limitations and negative results. See the repository README for what is implemented, what is deployed, what is still experimental and what is pending.
THE QUESTION
How far can the software lifecycle be automated when agents hold credentials, run untrusted code and act with limited oversight?
THE EXPERIMENT
Narrow agent roles, disposable sandboxes, short-lived credentials and a durable workflow, tested mission by mission.
THE LEARNING
What works, where it fails and which patterns are worth evaluating elsewhere. A human gate stays before every merge.
How a mission flows
Six durable phases. Select a step to see what happens and which component is responsible.
Core components & tech stack
Ten isolated Kubernetes namespaces, grouped into four layers.
Design choices under test
Human in the loop
The factory proposes. You decide.
Agents open pull requests and attach test evidence. Merging is a manual human action — enforced by branch protection, not by convention. You can steer a live mission straight from a PR comment.
# Directives on any pull request
@darkgravity /status — live DAG & sandbox health
@darkgravity /interact <question> — ask the planner
@darkgravity /refine <change> — surgical edit
@darkgravity /validate — full tests + SAST
Repositories
Projects, curated
Repositories grouped by function: Dark Gravity (autonomous engineering lab), infrastructure & GitOps (do ideas survive deployment, limits and recovery?), and LLMOps, agents & knowledge systems (RAG, multi-agent orchestration, evaluation, observability). Every card links straight to the code.
Fork note: Forked repositories in this lab are maintained separately to stay independent of upstream license and release changes, at the cost of extra maintenance. Learn more in the Fork Policy.
Follow the experiments.
The best quality signal is not that Dark Gravity looks perfect, but that anyone can follow how it evolved, why decisions were made and what was learned by testing them.