Paper — every trading figure here (positions, orders, P&L, equity, returns) is simulated on an Alpaca paper account. No real capital is at risk, and no order is ever placed with your money. Running costs shown under ops, such as LLM spend, are real.

Going deeper

Public

Understanding Portfolio Risk

Your preference, the protection actually running, and the system's hard safety limits are related — but they are not the same thing.

The four values to know

  • ·Requested policy — the risk level and advanced choices you ask for.
  • ·Derived policy — the position size, position count, and loss limits calculated from your request and allocated capital.
  • ·Effective policy — the approved limits the trading engine has acknowledged and is enforcing.
  • ·System safety ceiling — the maximum protection boundary. Your policy can be safer, but can never loosen this boundary.

The number that protects your money

When requested and effective values differ, trust the effectivevalue. A request is not active merely because it was saved or staged. Today the daemon's acknowledgement proves only that it validated and staged the same version/hash; #263 must separately authorize and report activation.

How the max-five paper ceiling is exposed safely

ADR-040 sets the paper engine's aggregate broker-active ceiling to five positions. It also caps every broker entry at the lower of $10,000, 10% of current account equity, or the strategy request. Five is a ceiling, not a deployment target; bucket, heat, notional, concentration, and drawdown gates may admit fewer positions.

Settings publishes a versioned, tenant/profile-bound policy through the durable APP-060 transport. The local daemon independently validates and stages the exact revision and acknowledges its version and content hash. That acknowledgement proves staging occurred; it does not activate the policy or prove current daemon liveness. Runtime activation remains fail-closed under #263.

The risk dial and advanced tuning

The 1–10 dial is the simple way to express risk intent. A higher number can request larger positions, more concurrent positions, or wider drawdown bands, but it does not grant them automatically. The system derives a complete policy, checks every safety rule, and applies tighter strategy and system limits before anything can become effective.

Advanced tuning is for people who need explicit controls — for example a lower position count, tighter heat limit, smaller position size, or an earlier drawdown pause. Advanced choices refine the same request; they do not bypass the dial or create a second hidden policy. Invalid combinations are rejected rather than quietly adjusted.

Examples

  • ·You publish a maximum of five positions. It is within the system ceiling, so it can be staged, but remains non-active until the separately approved activation path exists.
  • ·You request a maximum of two positions. Because this is tighter than the ceiling and the rest of the policy is valid, two can be staged for later activation review. The acknowledgement is not activation.
  • ·You request six positions. The API rejects it because every rung from 6 through 9 belongs to #257's separately audited evidence gate.
  • ·A revision is partial, stale, cross-tenant, or hash-mismatched. The transport rejects it instead of guessing which limits you intended.

Why a request can be rejected

The transport rejects rather than silently reshapes. Every rejection returns an explicit reason so you can see exactly which safety rail intervened.

  • ·Above the system ceiling. Any request that names more than five broker-active positions, or a per-entry position cap above 10% of current equity, or a per-entry notional above $10,000, is rejected. Rungs 6–9 are gated by #257's evidence canary, not the dial.
  • ·Non-monotonic drawdown thresholds. The reduce, pause, and halt levels must strictly increase. If you request pause 0.05 with reduce 0.10, the API returns 422 policy_rejected — reversing the order would let a mild drawdown halt trading before the reduce step ever fired.
  • ·Stale or replayed revision. The API keeps every revision by version and content hash. Submitting an expected_versionthat no longer matches the head is rejected. Retrying the current payload is safe and does not create a duplicate; restoring an older policy is published as a new, higher revision. The UI reloads the current head before a changed policy is published.
  • ·Cross-tenant or cross-profile.The tenant identity comes from the authenticated session, never from the request body. A tenant cannot publish, read, or acknowledge another tenant's revisions; those calls are refused before any policy math runs.
  • ·Partial or malformed revision. Every field the schema requires must be present and typed correctly. Missing or malformed fields are rejected wholesale — the API does not guess a plausible value or fill in defaults from a different revision.

What the state labels mean

  • ·Compiled ceiling. No revision has been staged for the selected portfolio. The runtime is operating against the compiledADR-040 ceiling: five positions, 10% per entry, $10,000 per entry. Nothing you have configured in the UI is live.
  • ·Staging pending. A revision was accepted by the API but the daemon has not yet reported an acknowledgement for its exact version and hash. The daemon checks for staged revisions on its regular five-minute transport poll; the UI polls every five seconds while a revision is pending.
  • ·Staging stale. The current head revision has a higher version than the last daemon acknowledgement. The daemon is still operating against an older revision, or the daemon is not running. Do not treat stale as active — the newer revision has no runtime effect.
  • ·Staged — not active. The daemon acknowledged the exact head revision by version and hash. The revision is stored durably and is ready for the separately audited activation path. Staging is not activation — no runtime policy has changed yet.

Active/canary trades and paper shadows are separate

The active/canary plane starts from the max-five paper baseline. Any future promotion is one rung at a time — 5→6→7→8→9 — with evidence-based sizing and rollback to the last accepted rung if a safety rail is breached.

The Research Lane is different. It is a paper-only evidence lab: exactly $100 per hypothetical trade, no more than three shadow variations of one parent signal, no more than 21 open shadows, and no more than $2,100 in total. It makes no broker calls and consumes none of the active account's position, heat, or spending limits.

Three shadows do not mean three independent wins

Variations created from the same ticker, signal, and time are siblings. They are useful comparisons, but they are correlated and count as one parent evidence unit when judging whether a strategy has enough data.

For the broader safety layers, read How Your Capital Is Protected.