A practical guide to explanation of watchlist-derived opportunity records in TEMIRIN using configured records, explicit market identity, current controls, and human review.
August 3, 2026 · 6 min read
A TEMIRIN opportunity record begins with a Polymarket market that a user has already placed on the workspace watchlist. The record is therefore watchlist-derived: it helps reviewers organize a known contract, not discover every market or rank a hidden universe. This distinction should appear in product copy, exports, and team training. Coverage depends on the markets and sources the workspace configured, so absence from the queue is not evidence that an outside contract lacks relevance.
The market identity should include the exact market ID, question, outcome side, closing condition, and resolution source available from public venue data. Review those fields before discussing evidence or price. Contracts with similar titles can differ by date, geography, threshold, or authority. A clear identity card prevents a note, alert, paper order, or public-wallet position from being attached to the wrong question and gives support teams a stable key for tracing the record.
Configured RSS and HTTPS web readers store evidence with canonical provenance and deduplication, while provider-configured Telegram and X readers can store their own source references where available. An item appears beside the opportunity when it carries a supported explicit market identifier. This explicit path keeps every evidence link inspectable and gives unlinked source material an honest state.
For every linked item, show publisher or provider, canonical URL or reference, observed time, supplied publication or event time when present, and safe processing status. A deterministic brief can organize those stored fields without generating a truth judgment. Reviewers should open the source, identify the precise claim, trace syndication, and note preliminary or corrected material themselves. A successful collection record says the item was stored; it does not establish that the claim supports the market outcome.
When the opportunity record is first created, TEMIRIN preserves the observed trigger price as a historical reference. Later market synchronization can update a separate current-price field without overwriting that first value. Both need their own timestamps. The pair helps a reviewer see how public context changed after the record began, but the trigger is not a recommendation, reserved quote, or promised entry. It records what the workspace saw, not what a user could necessarily execute.
Public bid, ask, spread, and visible depth can provide additional book context when available. Label each field precisely instead of calling every value “price.” A midpoint inside a wide spread may not be tradable, and displayed depth may change rapidly. Reviewers can add these observations to their notes while keeping the implemented policy result and user-entered paper-order checks separately identified.
A record can display current workflow policy such as a stake cap, source and category enabled or blocked state, source or category maximum-stake override, free-capital percentage, price-move guard, and kill switch. Explain the stored pass or block reason in plain language. User-entered paper orders also receive per-order, rolling twenty-four-hour, per-market exposure, and portfolio concentration checks before the simulation is saved.
The price-move guard applies at the authenticated decision endpoint. If current price has moved beyond its configured boundary, an attempted approve or reject can be blocked and returned for human review. The earlier record remains part of the audit trail with its original price and timestamp. Preserving both states makes later analysis clearer than silently updating the past to match current settings.
Alert rules may deliver opportunity context to configured email, Telegram, Slack, or outbound webhook destinations. Each attempt belongs in the delivery ledger and can be retried manually after failure. Delivery status does not change the opportunity’s decision state, acknowledge a task, or authorize action. In-app approve and reject are separate authenticated events with an actor and time. External channels are useful for attention, while the workspace remains the place where decisions are recorded.
A paper order is a user-entered simulation stored in its own ledger. The server checks per-order and rolling twenty-four-hour notional, per-market exposure, and portfolio concentration, then returns a pass or block result without suggesting an amount. A configured public wallet supplies read-only snapshots and position context in another lane. Never merge the paper record with public-wallet activity or imply that an approval caused a real venue transaction. TEMIRIN neither places orders nor moves funds.
A strong opportunity record lets a later reviewer reconstruct the decision without guessing. Add an attributable journal note covering the thesis, linked evidence, uncertainty, disposition, and any manual condition the reviewer considered. Preserve rejected, blocked, and no-action records alongside paper entries. When new evidence or a correction appears, append it rather than editing the original trigger, decision, or reasoning. That chronology is more useful for learning than a polished narrative assembled after resolution.
Journal analytics and export can compare process patterns across a defined sample, provided labels stay honest. Trigger-to-current movement, paper mark-to-market, and public-wallet PnL use different data and must remain separate. Report missing fields and sample counts. The record’s purpose is explainability: it joins known market identity, explicit evidence, timestamped price context, policy state, delivery history, human decisions, simulations, and notes while leaving interpretation, capital, and every real Polymarket action with the user.
For a support investigation, start with the opportunity ID rather than a screenshot. Confirm workspace access, watchlist identity, trigger time, last market sync, linked source records, policy reason, and the actor attached to any decision. Then inspect alert attempts and paper activity in their own ledgers. This sequence reveals whether the reported problem concerns source ingestion, explicit linking, price freshness, delivery transport, authorization, or simulation controls. It also prevents an outside wallet change from being misreported as an action taken by TEMIRIN.
Teams can use a short explanation standard for every record selected during a review: why the market was watched, which explicit evidence mattered, what changed since the trigger, which constraint applied, what the reviewer decided, and what remained uncertain. The standard is a writing discipline, not an automated workflow state. Applying it to rejected and untouched records as well as paper entries produces a more representative history and helps new teammates understand both the product boundary and the team’s own judgment.
If two records appear to refer to the same contract, compare their stable market identifiers and creation history before merging any human notes. Keep the preserved trigger belonging to each stored record until the duplication is understood. A correction should be attributable and should not erase decisions already made. This protects the explanation chain from a cleanup step that would otherwise make past reviewers appear to have seen different context.
Because it begins with a market the user deliberately configured in the workspace watchlist, making coverage visible and attributable.
A stored item carries a supported explicit market identifier that matches the configured watchlist record.
The trigger is the first price preserved with the record. Current price is a later public observation with its own timestamp; neither guarantees an executable quote.
Alert delivery, authenticated approve or reject, and a user-created paper order use separate records, actions, actors, and timestamps.
It records that the user-entered simulation passed the implemented notional, exposure, and concentration checks at that time.
