Design prediction-market kill switches that stop new actions safely, scope incidents, request a fresh in-app review, preserve audit evidence, and govern recovery.
August 3, 2026 · 3 min read
TEMIRIN stores a workspace investment-policy kill-switch setting. When enabled, opportunity policy evaluation adds a blocked reason and returns the record as ineligible for the product’s review progression. The default policy is fail closed. This is a current record-level control, not a claim that TEMIRIN cancels venue orders or exits positions.
The switch belongs beside the active policy version and should be visible anywhere a user reviews eligibility. A blocked reason is more useful than a hidden disabled button because it explains why the workspace stopped.
The current switch participates in opportunity policy evaluation and records its reason in stored policy status. It can prevent an opportunity from appearing eligible inside TEMIRIN. It does not pause RSS ingestion, disable every connector, retract external alerts, cancel open Polymarket orders, or move wallet funds.
Operational playbooks may use broader stop procedures outside the product, but those practices should not be advertised as current software behavior. Keep the public description tied to the stored setting and policy result.
A policy change should be workspace-scoped, role-aware, and audit logged with safe metadata. The review should identify the actor, timestamp, resulting switch state, and policy version without copying credentials or wallet secrets. Teammates can then reconstruct why opportunity records became blocked.
Do not infer a recovery rule from elapsed time. An authorized user should review the cause and deliberately change the setting only when the workspace’s own requirements are met.
Create a watchlist-derived opportunity under a configured policy, enable the kill switch, sync the opportunity record, and confirm that eligibility is false with the expected blocked reason. Verify that the page does not suggest a paper order can bypass the block and that teammates see the same stored state.
Then test missing portfolio data, low confidence, blocked category, and disabled source overrides separately. Distinct reasons matter because a kill-switch incident and an ordinary policy rejection require different follow-up.
A kill switch cannot remove prediction-market risk, guarantee that external activity stopped, or establish legal eligibility. It is one current policy boundary inside a research and paper-order workspace. Users remain responsible for their wallets, venue accounts, and real orders.
The value is explicit fail-closed state: TEMIRIN can show that its own opportunity workflow is blocked instead of presenting uncertainty as permission.
Include the kill-switch state in support diagnostics and account export so users can understand why records were blocked and retain their policy history. Account export should include the workspace-scoped policy and its current stored state. These lifecycle behaviors keep the control accountable without suggesting it reaches beyond TEMIRIN into an external venue or wallet.
Review the setting during onboarding and team handoffs so every authorized member understands its narrow effect. The switch blocks TEMIRIN opportunity eligibility; it does not contact Polymarket, revoke external credentials, or close exposure. If a user needs to stop real venue activity, they must use the venue and wallet controls available to them. Repeating this distinction in support guidance reduces the risk that someone relies on an internal policy flag as a universal emergency control. Keep a dated support note that states the same boundary, points users to their own venue procedures, and names the workspace policy owner. During a drill, verify the in-product blocked reason and separately verify the user’s external venue response plan. Recheck the control after permission changes, policy edits, or workspace migrations. A simple drill should create an otherwise eligible opportunity, confirm the stored blocked reason, restore the prior setting deliberately, and retain the resulting audit events for later review.
It should stop new actions within its configured scope and expose the blocked state to reviewers. The control should not silently erase evidence, notes, prior decisions, paper records, or the incident trail.
Keep the affected scope, activation time, actor, reason, policy state, related alert or paper records, and subsequent review notes. Preserved context makes the interruption explainable and supports a controlled recovery review.
Confirm the incident scope, source and market-data health, current policy values, assigned owner, and a fresh in-app review. The recovery note should explain why the condition is understood and who cleared it.
