Projects
Projects for the parts of AI that break after the demo.
5D is the runtime policy engine. DotOS is the larger systems lab. One lives at the tool boundary. The other tests what autonomous work needs once chat is no longer enough.
Runtime policy
5D Runtime Policy Engine
5D exists for a narrow, real problem: agents that can run tools need a policy layer at execution time. Prompts are not enough. If the agent can write files, run shell, hit APIs, or touch credentials, you need a place to decide whether that action should run, be reviewed, or be blocked.
The current shape is deliberately small: score the action, gate the action, log the outcome, and optionally hand risky decisions to a user or a separate review agent. That is the kernel.
Systems lab
DotOS
DotOS is where the larger architectural questions get tested. How should goals become tasks? What belongs to a model, what belongs to code, and where does human oversight enter the loop once agents move from chat into coordinated work?
It is local-first, orchestration-heavy, and honest about the hard parts: memory, governance, retries, execution boundaries, and the cost of letting agents act in the real world.
What ties them together
Policy belongs at the action boundary
- Risk should rise with consequences, not with UI noise
- Approval should appear where side effects begin
- Longer loops need guardrails, not blind trust
- Logs and review paths matter more than another safety slogan
Why 5D exists
Because approval fatigue and risky tools are both real
The chatter is consistent: builders want agents to run longer, but they do not want to approve every harmless read or silently allow shell, write, and network actions with real blast radius. 5D is built exactly for that tension.
Reading Path
Related writing
Short essays on approval fatigue, runtime policy, zero-fabrication architecture, and the larger system decisions behind both projects.
Read the related writing