Workers and leases
Event log and audit trail
Overseer: people across projects
Who is on what, and why a decision is waitingDecisions waiting on a person
Roles per project
One person, different roles in different projectsRisk classes decide who must be present
Two layers of rules
Shared engineering principles
Nineteen principles, the gate discipline and the session types, kept in one process repository. Every project vendors them, and drift from them is a red gate, so projects cannot silently diverge.
Each project's own instance
Its plans, autonomy level, spend ceilings, members and roles. A project tightens or loosens what it may, inside the shared principles.
The overseer layer above
Sees people, load and waiting decisions across every project, so a stalled review has a visible reason and a route forward.
What this is
A clickable design demo of a central control plane for the Xal Software Factory. The factory is real and open source: specs, plans, a driver that runs agents headless, gates that decide, a pinned reader agent, and a merge script. Today its pipeline runs in GitHub Actions and its human loop runs on one developer's machine. This demo shows the next layer, where the human loop is central too.
What it shows
- Gates decide, never the agent. Each stage names its decider: a script, a pinned agent, a router, a person or a policy.
- Event-driven handoffs. A completion triggers the next step. A decision that needs a person is routed to an eligible, available one, on their channel.
- Availability-aware routing. A reviewer who is mid-review on another project is skipped, and the reason is logged.
- Concurrency without collisions. Sessions across projects run at once on a worker pool, each holding a lease so no two workers take the same session.
- Roles per project. One person can review in one project and only view in another. The inbox and its buttons follow the role.
- Channel limits by risk. Code-only work merges unattended inside the autonomy level. A public surface needs a reviewer, from any channel. Infrastructure needs an authenticated review in GitHub, and a chat button is refused.
- Refusal before spend, retry caps and escalation. A project with no autonomy level is refused before anything runs. A gate that keeps failing escalates to the owner instead of looping.
- The audit trail stays in git. Every approval or ruling made in a channel is recorded as a GitHub review or a commit by that person.
What it is not, yet
No agents, repositories, accounts or messages are involved. Nothing leaves your browser and nothing is stored. The people and projects are examples. The design itself is under research: identity and verification, sandboxing per session, the lease store, and the channel integrations.
Try this
- Press Play. Watch xal-notify S4 fail its gate once, retry and merge with no person needed, then trigger S5.
- As Ada, leave the invoicing review open. When S5 needs a reviewer, the router skips Ada and picks Tomi on Telegram.
- As Sodiq, try approving the infrastructure heads-up in Slack. It is refused. Switch to Kemi and approve it in GitHub.
- As Sodiq, rule on acme-orders, which was refused because its autonomy level is unset.
- Press Break the gate on a running session to watch it exhaust its retries and escalate.
Built by Babatunde Adenowo (xodeeq). Factory docs: factory.getxal.com.