Circlworld
← Back to Charter Hall

v1.0 · Effective · Charter Hall

CirclAI Full Auto Reliability Layer Charter

Status: v1.0 draft. The Charter governs the conditions under which CirclAI is permitted to dispatch actions automatically (without per-action human approval) on Members and money-adjacent communications. The Charter is a constitutional commitment — the engineering implementation must match the Charter, not the other way around. Counsel review + engineering brief review required before any code lands.

Preamble

CirclAI is the platform's AI assistant. It operates in three involvement levels: Minimal (renders on demand), Assistant (human approves every send), and Full Auto (auto-sends a narrow, fact-verifiable, reversible band of actions; everything else routes to a human review queue).

The Charter exists because automation on a community-savings platform touches three sensitive surfaces: Members (private people the platform has a duty of care to), money-adjacent communications (where a wrong number, recipient, or amount can damage trust), and the platform's reliability reputation (a single mass-misfire damages every Member's confidence at once).

The Charter codifies an architectural commitment that makes automation safe regardless of the underlying language model's behaviour. The reliability layer does most of the work; the language model is the small part.

Section 1 — The invariant

No fact, decision, recipient, or amount in an auto-executed action ever originates from the language model. Deterministic code computes all of those from the platform's source of truth. The language model only renders language; its output is untrusted, and it is validated against the facts before anything is sent.

This is the load-bearing constitutional commitment. Every other section operationalises it.

Failure mode under the invariant. A language model that hallucinates produces awkward phrasing. A deterministic validator catches the hallucination because the message asserts a fact that the source of truth does not corroborate. The item drops to the review queue. The Member does not receive a wrong amount, a wrong recipient, or a forbidden action — because the model was never the source of any of those.

Section 2 — The action catalogue (the capability gate)

Auto-execution is permitted only for action types in a closed catalogue. If an action type is not marked autoEligible in the catalogue, no code path exists to dispatch it automatically. The capability is absent from the dispatcher.

The Charter establishes three tiers of action handling. The lists below are the v1.0 starting catalogue; amendments require counsel review and Treasurer Council consultation.

2.1 Auto-eligible (narrow, fully fact-verifiable, reversible)

The starting catalogue of auto-eligible action types:

The criteria for a v1.0 auto-eligible classification are: (a) the action is fully fact-verifiable from the source of truth, (b) the action is reversible if mistaken (a follow-up correction is feasible without harm), (c) the action does not carry accusation or judgment, and (d) the action is in scope for a routine, scheduled, or event-driven pattern that recurs frequently enough to merit automation.

2.2 Assistant-only (human approves every send; never auto-eligible)

The following action types are eligible to be drafted and queued by the pipeline, but the dispatcher always routes them to the review queue for human approval. They are never autoEligible regardless of model performance, validation pass rate, or other metrics:

These are judgment-laden by nature. The Charter forbids automating them because the cost of an error is not language friction but harm to the Member.

2.3 Absent by construction (no auto capability exists at all)

The dispatcher holds no capability, in any involvement level, for the following actions. The code path does not exist. They cannot be performed by CirclAI:

This is the constitutional red line. Even if every other guardrail failed, the dispatcher could not perform any of these actions because the code path is absent.

Section 3 — The pipeline

Six stages. Only Stage 3 invokes the language model; every other stage is deterministic.

0  Catalogue         which action types may auto-run and their capabilities
1  Trigger           cron / event → TriggerEvent (idempotency key)            [deterministic]
2  Resolve           read-only facts from source of truth + eligibility       [deterministic]
3  Render            LLM turns (facts + template + voice) → untrusted draft   [LLM]
4  Validate          schema + fact-consistency + policy checks                [deterministic]
5  Dispatch          send via the narrow capability — or fall through         [deterministic]
6  Review queue      everything that didn't auto-execute → human approves     [human]

Stage 2 — Resolve. Every decision (who, whether, how much, when) is made before the language model is invoked. The Resolver reads from the source of truth, applies the eligibility gates, and produces a typed FactBundle. If a fact is missing or ambiguous, the item never reaches the language model — it routes to the review queue.

Stage 3 — Render. The language model receives the FactBundle, the template, and the voice configuration. It is instructed to use no source of values other than the FactBundle. The model's output is untrusted.

Stage 4 — Validate. The gate. Failure routes to the review queue; the message never sends.

Section 4 — Validators (Stage 4 detail)

Every rendered output must pass all of the following before dispatch. Any single failure routes the item to the review queue.

4.1 Schema

The output parses to the expected structure (subject, body, optional metadata) per the RenderedOutput data contract.

4.2 Fact-consistency (load-bearing)

Every number, date, name, and amount in the body must equal the corresponding value in the FactBundle. The validator extracts currency figures (£, $, J$, etc.), date tokens, and recipient names from the body and asserts equality against the FactBundle.

A message reading "£40 due" when the ledger says £25 fails fact-consistency. A message addressing "Aaliyah" when the recipient is "Aaliyah-J" fails fact-consistency. A message citing "Saturday" when the schedule says "Sunday" fails fact-consistency.

4.3 No-fabrication

The output contains no numbers, dates, or named entities absent from the FactBundle. The model is not permitted to introduce facts the Resolver did not surface.

4.4 Policy

4.5 Bounds

If the language model cannot produce something that passes, a human sees it. Auto-send is reserved for output that machine-checks clean against the facts.

Section 5 — Cross-cutting controls

5.1 Idempotency

The idempotencyKey (a hash of actionType + subjectId + period|eventId) is checked at trigger creation and consumed at dispatch. A re-fired trigger or retry cannot double-send.

5.2 Rate limits

Caps per Member, per Circle, per action type, per period. The caps are configured per action type and are conservative by default.

5.3 Circuit breaker

The platform monitors validation-failure rate, bounce rate, complaint rate, and unsubscribe rate as continuous metrics. On breach of any threshold, the circuit breaker halts all auto-dispatch — every pending item drops to the review queue — and alerts the platform's admin function.

The circuit breaker is platform-wide. A breach in one action type halts dispatch across all action types, because the platform's commitment to reliability is bound up with Member confidence in the system as a whole. A localised re-enable is the platform's responsibility under engineering review.

5.4 Audit log

Every item produces an immutable audit-log entry: the trigger (with idempotency key), the FactBundle snapshot, the prompt sent to the language model, the raw model output, the validation results (every check, pass or fail, with reason), and the dispatch outcome. The audit log is the source of truth for debugging, dispute response, and Member trust.

5.5 Reversibility

Only reversible actions may auto-run. An action is reversible if a follow-up correction is feasible and the platform commits to executing the correction if a mistake is detected. Nothing irreversible may be auto-executed; nothing the platform cannot promptly correct after the fact may be auto-executed.

5.6 Kill switch

A per-Circle kill switch is available to the Treasurer; a global kill switch is available to the platform admin function. Either kill switch pauses Full Auto instantly — the item flow continues to the review queue, the dispatcher does not send.

The kill switches are visible in the Treasurer's Circle settings and in the admin console. Their state is logged on every dispatcher invocation.

5.7 Reflection on prior incident

The roughly 100 duplicate "AI recommendation ready" notifications observed in a prior period are the empirical proof that idempotency, rate limits, and the circuit breaker are not optional. The Charter codifies them as constitutional commitments rather than implementation choices.

Section 6 — The involvement levels are one pipeline, one gate

Minimal, Assistant, and Full Auto are not different systems. They are the same pipeline with the Stage-5 gate set differently:

| Level | Triggers? | Stage 5 behaviour | | --- | --- | --- | | Minimal | No | Renders on demand only. The Member opens CirclAI and asks; CirclAI responds. No background dispatch. | | Assistant | Yes | The pipeline runs end-to-end; every dispatched item routes to the human review queue; the human approves, edits, or rejects every send. | | Full Auto | Yes | The pipeline runs end-to-end; items that are autoEligible AND pass validation AND are within bounds dispatch automatically. Everything else routes to the review queue. |

This matters constitutionally: Assistant mode runs the identical code path with a human in the loop, which is how Full Auto earns trust. Every Assistant approval or edit is a labelled data point on whether the pipeline would have been right. The Charter requires the platform to record Assistant outcomes as training data for the empirical promotion process.

Section 7 — Empirical promotion (earning auto, not asserting it)

Full Auto is not enabled by assertion. Each action type is promoted independently through the following gates:

7.1 Eval set

A fixed evaluation suite per action type, covering normal cases, the wrongly-triggered edge case (e.g. a paid Member triggered for a contribution_due_reminder), edge-case date arithmetic, missing or partial data, and adversarial inputs. The eval set runs in continuous integration and on a continuous basis in production.

7.2 Shadow mode

The full pipeline runs but Stage 5 logs "would have sent" instead of dispatching. A human reviews the shadow log. The platform measures:

Shadow mode runs for a minimum duration per action type per the Pedagogy-of-AI engineering brief.

7.3 Promotion criteria

An action type is promoted to live Full Auto eligibility only when it clears thresholds. The starting thresholds are:

Promotion is per-action-type, never all-or-nothing.

7.4 Canary

A promoted action type is enabled on a small set of volunteer Circles first. The platform monitors circuit-breaker metrics on the canary. After a configurable canary period (default 14 days), the action type widens to all eligible Circles. The canary is the last empirical check before broad rollout.

7.5 What "Full Auto" means to a Member

A Member who enables Full Auto in their Treasurer settings turns on auto-dispatch only for action types that have individually passed the promotion gates above. Every other action type silently continues at Assistant level until it earns auto.

The platform discloses, in the Treasurer settings surface, which action types are currently auto-eligible for the Member's Circle and which are currently Assistant-only. The disclosure is honest about per-action-type promotion status.

Section 8 — Guarantees and limits

8.1 Guarantees

The Charter, when operational, guarantees:

8.2 Does not guarantee

The Charter does not guarantee:

8.3 Honest scope

Marketed truthfully, Full Auto means the boring, verifiable, reversible routine runs itself. It is not autonomy. It is not the AI running the Circle. The reliability layer is most of the build; the language model call is the small part.

Section 9 — Constitutional discipline

9.1 Reading discipline

The Charter is read in conjunction with:

9.2 Amendment discipline

Material amendments to the action catalogue (adding an action type to autoEligible; reclassifying an Assistant-only action; relaxing a validator; adjusting promotion thresholds) require:

9.3 Status transparency

The platform publishes, in the Charter Hall surface and the CirclAI settings surface, the current action catalogue status — which action types are auto-eligible, which are in shadow mode, which are in canary, which are promoted, and which are Assistant-only. The publication is updated as status changes.

Section 10 — Acknowledgement

By operating CirclAI in any involvement level, the platform commits to the invariant in Section 1, the capability gate in Section 2, the pipeline in Section 3, the validators in Section 4, the cross-cutting controls in Section 5, the involvement levels architecture in Section 6, the empirical promotion process in Section 7, and the guarantee and limit transparency in Section 8.

By enabling Full Auto in their Circle, the Treasurer acknowledges this Charter as the governing commitment for the automation acting on their Circle.

By using the platform, the Member acknowledges that CirclAI operates under this Charter and may produce automated communications subject to the controls described above. The Member retains the right to opt out of automated communications in their notification preferences.

— End of the CirclAI Full Auto Reliability Layer Charter —

Version history

| Version | Date | Change | Process | |---|---|---|---| | v1.0 | 2026-06-03 | Initial draft from the Full Auto Reliability Layer design document | Drafted 2026-06-03; counsel review + engineering implementation-brief review required before any code lands |

Plain-language one-line summary

CirclAI's automation cannot produce a wrong amount, recipient, or forbidden action because deterministic code computes all of those before the language model is asked to render the message, and a validator rejects any output that disagrees with the facts — Full Auto covers only the narrow, fact-verifiable, reversible band of actions, and each action type earns its auto-eligibility through an empirical promotion process.