Software is broken. Not for lack of power, but for a lack of perspective.
We are still programming outcomes using procedures.
For 70+ years, we've relied on:
- ❌ Imperative logic & fragile workflows
- ❌ Endless glue code and complex orchestration
- ❌ Human-managed control flows
We write how to do things. We debug why they broke. We maintain systems we barely understand. And then we call this engineering.
UGEM replaces procedural execution with Goal Resolution.
You no longer wire services or orchestrate logic. You simply declare:
"What must be true."
The system then deterministically figures out how to make it true.
Goals → Events → State → Actions
- ❌ No controllers
- ❌ No queues or crons
- ❌ No fragile orchestration engines
✅ Just pure, deterministic computation driven by intent.
We have reached the limit of imperative complexity. UGEM provides the foundation for the next era:
| Need | UGEM Solution |
|---|---|
| AI Foundations | Deterministic execution for non-deterministic minds |
| Autonomous Agents | Goal-native environments for true agency |
| Formal Correctness | Systems that prove their own behavior |
| Human Simplicity | Shifting the cognitive load from "How" to "What" |
UGEM is not a framework or a runtime — it is a new computational model.
It enables:
- 🤖 AI-Native Software — Built for the era of intelligence
- 🔄 Self-Healing Systems — Discrepancies between State and Goal trigger automatic correction
- ⏪ Time-Travel Debugging — Deterministic replay of every intent
- 🚫 Zero Orchestration — The end of boilerplate "plumbing" code
This is not low-code. This is post-code.
| Era | Past | UGEM |
|---|---|---|
| Evolution | Assembly → High-level Languages | Instructions → Outcomes |
| Recent | Physical Servers → Cloud | — |
🛠 Production Readiness Status To be transparent with early adopters, here is our current "Path to Production" checklist:
[x] Core Kernel: Functional deterministic resolution loop.
[x] GDL Parser: Initial specification and parser complete.
[/] Stress Testing: Ongoing (identifying edge cases in high-concurrency goal resolution).
[ ] Security Auditing: Internal review of the security/ module pending.
[ ] Distributed Consensus: Hardening leader election in unstable network conditions.
[ ] Performance Benchmarking: Baseline metrics for goals/sec are being established.
UGEM is for builders who believe:
- ✅ Software should explain itself
- ✅ Systems should prove correctness
- ✅ AI should execute, not hallucinate
- ✅ Scaling should not increase complexity
- Coming Soon: SDKs for Go, Python, and TypeScript.
UGEM is an open-source project, and we welcome community contributions! Whether you're fixing bugs, improving documentation, or proposing new features, your help is appreciated.
| Type | Description |
|---|---|
| 🐛 Bug Reports | Open an issue with reproduction steps |
| 💡 Feature Requests | Describe the problem and proposed solution |
| 📖 Documentation | Improve docs, examples, or this README |
| 💻 Code Contributions | Submit PRs for fixes, features, or refactoring |
| 🧪 Testing | Add tests or report test failures |
| 💬 Discussions | Participate in GitHub Discussions |
# Clone the repository
git clone https://github.com/ugem-io/ugem.git
cd ugem
# Install dependencies
go mod download
# Run tests
go test ./...
# Build the project
go build ./cmd/ugem- Fork the repository and create a feature branch
- Follow the existing code style (see Code Standards)
- Add or update tests as needed
- Ensure all tests pass:
go test ./... - Update documentation for any user-facing changes
- Write clear, descriptive commit messages
- Submit a PR with a detailed description
- ✅ Use meaningful variable and function names
- ✅ Add comments for complex logic
- ✅ Keep functions small and focused
- ✅ Write tests for new functionality
- ✅ Run
go fmtbefore committing - ✅ Run
go vetto catch common issues
For security vulnerabilities, please do not open a public issue. Instead, contact the maintainers directly through [email protected].
UGEM uses a split-license model to keep the core engine open while allowing commercial adoption:
| Component | Directory | License |
|---|---|---|
| Core Substrate (kernel, runtime, storage, planning, distributed, security, logging, observability) | /kernel, /runtime, etc. |
AGPL v3 |
| Integration Surface (GDL, plugins, sdk) | /gdl, /plugins, /sdk |
MIT |
- MIT — Use GDL and plugins to build proprietary business logic and commercial applications.
- AGPL v3 — Modifications to the runtime/kernel must be shared with the community.
See license_summary.md for full details.
Maintained by the UGEM Core Team. We are currently a small group of early contributors—your help can define the future of this project.
Made with ❤️ by the UGEM Community
UGEM is currently in its early stages, led by a solo architect with a vision for deterministic software. To reach production-readiness, we need you.
Whether you are a distributed systems expert, a GDL enthusiast, or a technical writer, your contributions will shape the foundation of post-procedural engineering.
- Founding Contributors: We are looking for early maintainers to help harden the
planning/anddistributed/modules. - Feedback: Join our GitHub Discussions to help refine the GDL specification.