Resolution criteria design example

API uptime resolution criteria package.

A compact example focused on making one market question objectively resolvable without drafting a full event contract specification.

Document type: Resolution Criteria Design Package
Prepared for: General product and operations review
Prepared by: Christopher Maximilian Altmann
Date / version: May 3, 2026 / v0.1-example

Document status

This example is a non-legal resolution-criteria design sample. It is not legal advice, regulatory advice, investment advice, a trading recommendation, a filing, or an instruction to operate or list a market.

Client input

"We want a market around whether Product A will be reliable enough after launch, but uptime definitions are easy to dispute."

Designed criteria

Market question

Will Product A maintain at least 99.9% monthly API uptime for every calendar month in Q4 2027?

Resolution time

After the final October, November, and December 2027 status reports and monitoring exports are available.

Primary source

Final internal SRE availability report generated from the production monitoring system selected before use.

Fallback source

Public status-page incident history and incident postmortems, used only if the primary source is unavailable or incomplete.

Yes criteria

Yes if each of October, November, and December 2027 has final measured API uptime greater than or equal to 99.9%.

No criteria

No if any in-scope month has final measured API uptime below 99.9%.

Invalid / review criteria

Review if the API boundary changes materially, the monitoring system is replaced without a continuity rule, or scheduled maintenance is not classified before use.