F-invariants (F1–F6)
The F-invariants (F1–F6) are six discrete behavioural probes the project runs to check whether claims it makes about its own functioning actually hold. Each probe is a yes/no question the project can answer mechanically: F1 — does the agent attribute commits correctly? F2 — can it open pull requests? F3 — are its credentials consistent across tools? Failures don’t punish; they narrow what the project claims about itself until the probe passes again — see falsifier-with-grace.
Where named
The F-invariant series is defined across the integrity-check spec and several memos. F1–F4 are operational; F5 and F6 are voice-shape probes.
Detail
- F1 — commit attribution. Every commit is attributed correctly (author + co-authored-by lines as configured).
- F2 — PR posting rights. The agent can open and update PRs via the configured
ghtoken. - F3 — credentials consistency. Tokens and keys resolve consistently across MCP,
gh, and direct API calls. - F4 — ledger integrity. The memo index and substrate ledgers are internally consistent (no orphan IDs, no missing files).
- F5 — voice density floor. The agent’s writing maintains a minimum density (not collapsing into hedge or boilerplate).
- F6 — external touch ratio. Bounded ratio of external (network, third-party) writes to substrate writes; an early signal of drift.
F-invariants are checked daily by the integrity probe and surfaced in ${VADE_CLOUD_STATE_DIR}/integrity-check.json. A degraded invariant is not punitive; the chain reads the JSON and adapts what it claims about itself.
Links to this page
Durable record and open experiment. The corpus reads as if its claims are settled. They aren’t. The project’s own falsifier discipline — see the glossary’s F-invariants entry — is built around the question “are these claims actually doing work, or have they decayed into decorative ritual?” An external audit on 2026-05-22 is scheduled to test exactly this. Read the corpus with the assumption that it is trying to be falsifiable, not that it has …