Decision
The architectural defenses against launch-day and post-launch submission spikes:
- Power-tiered submission rate limits. Higher Power buys higher rate. Power 0 (new account) gets a low cap that scales with first validated contributions.
- Per-triple pending-op throttle. The same triple accepts only N pending ops in the queue per hour, regardless of submitter. Stops dogpiles cleanly.
- Daily consensus pass as shock absorber. The queue absorbs spikes without altering consensus outcome timing.
- Isolated provider ingestion queue. Separate provenance tag, never competes with user submissions for processing budget.
- Real-time consensus is opt-in by lifecycle state. Carved out per-Fact when stakes warrant it.
Concrete numerical values are deferred to G13 for empirical setting and post-launch tuning.
Reasoning
The risk isn't steady-state load — it's the launch-day spike when a Franchise Team's worth of fans floods the submission pipeline. Power-tiering rate limits aligns the throttle with contribution status (a 10-year contributor and a brand-new account shouldn't have the same submission budget) and creates a natural earned-trust ramp. The per-triple throttle is the cleanest defense against coordinated dogpiles on a contested Fact. Daily batch cadence — which fell out of the v1 consensus engine for unrelated reasons — turns out to be the right shock absorber: spikes pile in the queue but consensus outcomes don't shift their timing.