Fiscal Charters

A ceiling moves only after approval and the timelock

Four signed records carry the change from proposal to the consumer that prices a call. The clock starts at admission.

1. 09:00, admission. The signed admission fixes admitted_at and the proposal expiry, and the one-hour clock starts.
2. 09:20, approvals. Two distinct charter members approve, each naming the same proposal and admission digests.
3. 09:30, too early. The threshold is met and the timelock has not elapsed, so no valid activation exists and the USD 1,000 schedule stays in force.
4. 10:00, activation. With every record inside its validity window and continuity checks passing, the consumer resolves USD 1,500 and retains the schedule id and sequence.

At the pricing or limit consumer, FiscalResolver::resolve takes the domain and the requested currency and returns a FiscalResolution. The consumer uses Governed parameters, handles the bootstrap Fallback only where the anchor proves the domain was never activated, and stops on Denied.

A charter governs five parameter domains of one deployment

A FiscalCharter (chio.fiscal.charter.v1) names the governing operator, its domains, an explicit signer set, and the amendment rules: approval threshold, timelock, and time-to-live windows. Each FiscalSchedule (chio.fiscal.schedule.v1) is a typed parameter set bound to that charter by digest, and its params variant must match its FiscalDomain.

The domains are the parameters live pricing and penalty consumers already read. Tier limits are the marketplace credit-limit tier ceilings and replace MARKETPLACE_TIER_LIMIT_UNITS. The discount is the reputation-tier invocation discount and replaces TIER_DISCOUNT_PER_HUNDRED in its per-hundred unit. Decision premiums are the underwriting basis-point tables, the insurance score_adjustments_bps are fixed-point, and the open-market schedule carries the exact OpenMarketFeeScheduleArtifact body as a bound compatibility projection. Premium money math is checked integer arithmetic, with finite f64 confined to behavioral risk classification.

Activation changes parameters and nothing else: it moves and holds no funds, issues no token, and takes no custody. A schedule is signed intent scoped to one charter, so it governs one operator's own parameters and carries no authority over a peer.

Four signed records carry a change, and one holds durable state

A FiscalProposal names a candidate schedule or a charter rotation. A FiscalProposalAdmission from the trusted admission authority stamps admitted_at, a checked-monotonic admission_sequence, and proposal_expires_at. Distinct members each sign a FiscalApproval, and a FiscalActivation aggregates them once the threshold is met and the timelock has passed.

The admission is the timelock anchor. Its proposal_expires_at equals admitted_at + proposal_ttl_seconds, each approval's approval_expires_at equals approved_at + approval_ttl_seconds, and the activation's activation_not_before equals admitted_at + timelock_seconds. A signed proposed_at or a caller-selected time leaves the delay unchanged.

Only the admission has stored state. FiscalProposalAdmissionState wraps the signed admission with its digest, a version, activationDigest, activatedSequence, and a status of admitted or activated; admission creates it at version 1 with both optional fields absent. The store records only those two values; awaiting signatures and waiting out the clock are conditions of the change. The state moves from Admitted to Activated by compare-and-swap, so two concurrent activations for one admission have exactly one winner.

Consumers read parameters through one resolver that fails closed

Consumers call one pure resolver instead of reading a parameter table. A Governed value exists only after the complete activation chain verifies: schema admission, every record signature, the locally anchored admission authority, threshold and uniqueness, the authenticated timelock, the validity window, the monotonic sequence, and the supersession lineage. The resolver walks a fixed order and stops at the first outcome it can prove:

1. Bootstrap. Fallback only when the anchored genesis checkpoint proves the domain was never activated, using the exact built-in constant or the pinned genesis-policy currency map.
2. Active. A verified, in-window active schedule resolves to Governed { source: Active }.
3. Last known good. When the newest candidate is bad, the prior verified in-window schedule resolves to Governed { source: LastKnownGood }.
4. Fail closed. With no valid charter, the resolver returns Denied, and the consumer does not price, bind, charge, or penalize.

Once the anchored ever_activated marker is true for a domain, unavailable governed state resolves to Denied and the built-in constant never reappears. Rejection and resolution are separate code paths, so a bad amendment leaves trustworthy state in place.

A stalled change has one of three causes. If the timelock has not elapsed, wait for the authenticated activation time; waiting leaves each approval's expiry where it was. If an approval expired, collect fresh approvals under a live proposal and admission, or prepare a new change. If continuity is unavailable, restore the checkpoint and anchor relationship. A signed timestamp is never edited to fit.

An anchor outside the database keeps an old schedule from returning

Local SQLite state is a cache and staging store. Resolution in production requires a configured FiscalStateAnchor that lives outside the database's backup and restore domain, such as a remote append-only witness or a hardware-backed monotonic store. Missing, unavailable, unauthenticated, or non-monotonic anchor state fails startup before any fiscal read or mutation is served.

The anchor holds the operator's latest signed chio.fiscal.continuity-checkpoint.v1: a monotonic continuity_sequence and the previous digest, the FiscalGenesisPolicy id and body digest, the pinned charter, the runtime-readiness digest, per-domain ever_activated with active and last-known-good heads, the trusted-clock high-water second, and any staged transition needed for recovery.

1. Stage. The transition and the next checkpoint are written in an Immediate SQLite transaction while consumers still read the prior state.
2. Swap. The independent anchor moves by compare-and-swap from the exact prior checkpoint to the next signed one. It accepts only a VerifiedFiscalContinuityAdvance: a continuity_sequence + 1 step, a non-decreasing clock floor, an unchanged genesis-policy digest, and an ever_activated bit that moves only from false to true.
3. Finalize. The local store finalizes against the anchored checkpoint.

A signed rollback, a skipped sequence, a cleared activation bit, or a reduced clock is rejected before the anchor mutates. Recovery reads the anchor first: if it is ahead of a restored database, the snapshot is stale and startup fails closed. Restoring SQLite alone can never reopen the bootstrap fallback or move the time boundary backward.

Next: wire governed parameters into an operating economy