What the Sibyl does

The Cumaean Sibyl wrote her prophecies on leaves and placed them at the entrance to her cave. If you arrived late, the wind had taken them. What remained was fragmented, out of order, impossible to reconstruct.

This is a system for catching the leaves.

What the forge produces

The rex-ai system — a self-hosted multi-agent AI infrastructure — produces genuine artifacts worth preserving beyond the context window in which they were made:

• Architectural decision records that capture not just what was decided but why, including the rejected alternatives and the conditions under which the decision would need to be revisited
• Governance patterns — the ISSUE_META schema, the tier-parallel principal model, the conductor/executor separation — that emerged from operational experience, not from design documents
• Session retrospectives that distill lessons from specific implementation cycles into reusable operational knowledge
• Capability milestones marking when the system crossed a threshold it couldn’t cross before

These live in private repositories, written in a register that assumes full context. They are not readable by an outside audience. A direct export would be raw material, not a finished artifact.

What Sibylance is

Sibylance is the curation and publishing pipeline that shapes raw forge output into dispatches — single publishable units, each one a leaf, caught.

The pipeline is deliberately human-gated. The system (EC — Execution Conductor) surfaces candidates when session output, ADR entries, or closed issue clusters reach a maturity threshold. The conductor reviews a rendered preview. Nothing publishes without approval.

This is not a blog in the conventional sense. There is no posting schedule. There is no audience optimization. Dispatches publish when something is worth publishing — when an architectural decision crystallizes, when a governance pattern earns its name through use, when a session produces a lesson that would have been lost in the space between context windows.

The name

Sibylance is a portmanteau of Sibyl and semblance. The appearance of the oracle; the captured impression of something that was briefly true.

The dispatches here are not the full system. They are the semblance of what came out of it — shaped for an outside reader who does not share the full context of the forge. The Sibyl’s prophecies, cleaned of the cave.

What gets published

The selection criteria, in roughly descending priority:

1. Architectural decisions that generalize beyond the specific system — patterns that would be useful to anyone building something similar
2. Governance patterns that emerged from operational experience — things that only become visible after you’ve built and operated a system for long enough to see what breaks
3. Session retrospectives when a specific implementation cycle produced lessons that warrant preservation in a form someone else could learn from
4. Capability milestones when the system demonstrates something that was previously impossible or impractical

Not published: internal operational logs, debugging notes, session artifacts that only make sense with full context, anything that would compromise the security or integrity of the infrastructure.

The publishing model

EC identifies dispatch candidate
→ conductor reviews in-chat preview
→ iterate until satisfied
→ conductor approves
→ EC commits to this repo
→ GitHub Actions deploys to GitHub Pages
→ dispatch is public

The conductor’s approval is the only gate. The Sibyl never publishes without the oracle being consulted.

This is the first dispatch. The system is now operational.