A practical guide to workspace role-based access in TEMIRIN using configured records, explicit market identity, current controls, and human review.
August 3, 2026 · 4 min read
Role-based access works best when it reflects real prediction-market desk responsibilities rather than impressive job titles. List who manages sources, curates the watchlist, reviews evidence, records approve or reject decisions, creates paper orders, inspects public-wallet context, exports journals, and administers destinations. Some people may hold several responsibilities in a small team, but writing them down reveals which actions genuinely need broader access and which should stay limited.
Begin with the least authority required for routine work, then add permissions for a documented purpose. A researcher who needs to read evidence and write notes may not need to alter connectors or export portfolio history. A workspace administrator may manage membership without being the person who interprets a market. TEMIRIN permissions protect application records; they do not grant or revoke rights at Polymarket, a wallet, or an external provider.
Not every public fact is low risk once it enters a private workspace. A public wallet connected to named research notes, team membership, alert destinations, and decision history can reveal strategy or operating patterns. Connector settings and delivery endpoints require tighter control even when their secret values are never displayed. Exports deserve explicit ownership because they move evidence, journal entries, and portfolio context beyond the application access boundary.
Build an access matrix around actions and data classes: view, create, decide, configure, export, and administer. Check authenticated routes and server authorization rather than relying on a hidden button alone. A copied deep link must still enforce workspace membership, and a user from another workspace must receive no protected content. External alert links should lead back through the same authentication and authorization checks.
An approve or reject record should identify the authenticated actor, workspace, opportunity, decision time, and available note. Preserve the market identity, trigger and current price context, and any price-move guard result that applied. If another reviewer later reaches a different conclusion, append a new attributable event or note rather than changing the original actor. This makes disagreement reviewable without pretending the software resolved it.
Approval decisions remain inside the authenticated application with an actor and timestamp. Telegram, email, Slack, and outbound webhooks can deliver review alerts when configured, and their attempts remain visible in the delivery ledger. Teams can document response-time expectations as operating practices owned by people. Real venue activity remains separate from both the workspace role and the approval record.
Membership changes are the moments when a clean role design proves useful. During onboarding, grant only the agreed workspace capabilities and explain what each protected record contains. When responsibilities change, remove old access before adding new authority. During offboarding, revoke workspace membership, rotate connector credentials when necessary, review destination ownership, and check recent exports. These steps do not end external venue or wallet access, which must be handled separately by their owners.
Retain an audit event for membership and important permission changes with actor, target, time, and safe reason. Avoid copying secret values into that history. Periodic reviews should compare the roster with current responsibilities, then sample real routes and actions instead of trusting the role name. A dormant account with broad privileges is an operational problem even when it has not produced a visible error.
Create a compact test matrix for evidence viewing, note creation, in-app decisions, paper-order entry, policy editing, destination configuration, wallet-context viewing, and journal export. For each action, test an authorized member, a member without the required access, a signed-out browser, and a user from another workspace. Confirm both the interface and server response, because client-only hiding is not an authorization control.
Repeat the matrix after changes to navigation, APIs, exports, or alert links. Inspect the resulting audit events and ensure denials do not leak record titles, addresses, notes, or destination details. A role system is effective when users can predict what they may do, administrators can explain why, and support can reconstruct a change. It should never be marketed as control over funds or an external trading account.
Include one stale session and one recently removed member in the exercise. Verify that revocation takes effect on protected reads as well as writes, and that previously copied URLs reveal nothing after access ends. Record the test date, workspace, cases, and owner without placing personal or secret data in the result. This creates evidence that the desk's access design works beyond its role labels.
No. They govern access to TEMIRIN workspace records and actions only. Venue accounts, signatures, funds, and wallet permissions remain in the user's external systems.
Only when that responsibility is part of the team's documented role design. Reading evidence and owning connector credentials are distinct operational needs.
Test protected reads and writes with authorized, unauthorized, signed-out, and cross-workspace users, and confirm enforcement at the server as well as in the interface.
