Use current source and category enablement, blocking, and max-stake overrides as visible prediction-market review context.
August 3, 2026 · 4 min read
TEMIRIN can enable or block a configured source and can store a source-specific maximum-stake override. It can do the same for a category. These fields are visible review context for a watchlist-derived opportunity and help a user keep one source or category from inheriting the workspace default without discussion.
Describe the controls exactly as enablement, blocking, and maximum-stake override fields. Store each value with its source or category identity, applicable policy reason, and version so the reviewer can reconstruct the context used by the record.
A source record identifies the configured RSS feed or HTTPS page that produced evidence. Its tier, reliability, relevance, direction, freshness, tags, and canonical URL remain inspectable beside the policy override and human review note.
A market relationship appears when a supported explicit market identifier is supplied. The reviewer verifies that link, checks the evidence and exact resolution wording, and reads the source override as a separate stored policy field.
Category enablement can keep a market theme inside or outside the configured review mandate. A category maximum-stake override can provide a narrower visible cap than the workspace default. When both a source and category setting apply, show the values and policy reason so the user can understand the current context.
Use the configured category label and policy values exactly as stored. Record later label corrections prospectively, keep their actor and timestamp, and leave market interpretation and eligibility with the reviewer.
The investment-policy surface also stores a workspace stake cap, confidence settings, free-capital percentage, price-move guard, and kill switch. The price-move guard is enforced at the in-app decision endpoint, and the kill switch affects opportunity eligibility. Users should treat other stored fields according to the explanation shown in the current product.
Paper orders have a separate implemented check set: plan-scoped per-order notional, rolling twenty-four-hour notional, per-market exposure, and portfolio concentration. A source or category override should never be described as a venue order, wallet action, or realized position.
When a user changes enablement or a maximum-stake override, retain the workspace scope, actor, effective time, and resulting value in the appropriate policy history. Earlier decisions should continue to show the context that existed when they were reviewed instead of being silently reinterpreted under the newest setting.
Sample blocked and allowed records periodically. Confirm that the source and category are correct, the stored override appears clearly, the explicit market link is valid, and the user-entered paper notional remains in its separate record. Correct confusing copy prospectively and preserve the original audit context.
This narrow scope is useful because clear enablement and maximum-stake context help a team discuss current workspace boundaries consistently while keeping human judgment separate from stored policy.
During policy review, sample one enabled source, one blocked source, one enabled category, one blocked category, and records with narrower max-stake overrides. Verify that each opportunity shows the applicable value and an understandable reason. Then change one setting in a test workspace and confirm that earlier audit context is retained while later records use the new value. Review alerts and exports for the same wording. This small matrix verifies the current feature set and exposes inconsistent policy labels.
Build a test matrix containing a workspace default, one source override, and one category override. For every row, record the source identity, category, confidence context, applicable maximum-stake values, resulting policy reason, and policy version. Compare an eligible record with a blocked one, then confirm that alerts, the protected review page, paper-order checks, journal notes, and exports name the same binding field. This gives operators a reproducible way to verify current override behavior after configuration changes.
A source override applies review context associated with one configured source, while a category override applies to records classified under that configured category. Both should identify the value and policy field used.
Display both current settings and retain the more restrictive applicable value in the paper-review context. The audit record should show which source and category settings were evaluated when the record was saved.
Store the blocked setting, applicable source or category, evaluation time, and reason beside the review record. A blocked state should be explicit rather than hidden behind a generic failure message.
