02 · Non-negotiable architectural decision

T3 remains the application; the Trading Mission Runtime is durable infrastructure, not a second trading brain

T3 is the primary runtime and control boundary. A harness turn is temporary; a trading mission is durable. The durable services that stay active between turns persist state, monitor typed events, enforce authority, and execute typed actions — but they never invent strategy, choose entries, or replace the selected harness with a hidden rules engine.

2.1–2.2 · What each side owns

T3 stays the harness manager; the runtime executes, it does not decide

T3 continues to own harness discovery, provider selection, session start and recovery, thread and mission association, tool provisioning, runtime-event ingestion, turn coordination, user conversation, persistent domain state, event scheduling and delivery, ordered UI projections, and pause, resume, and revocation controls. Trading is a first-class T3 orchestration domain — not a separate product-level strategy service that independently owns trading intelligence.

Harness owns (strategy actor)

The selected harness decides

When fresh trading judgment is required, T3 wakes the selected harness. The harness interprets the objective, makes discretionary decisions, and operates through typed tools exposed by T3.

T3 server owns (control boundary)

T3 manages the harness and execution

Harness discovery and availability, provider selection, provider session start and recovery, thread and mission association, tool provisioning, runtime-event ingestion, turn coordination, user conversation, persistent domain state, event scheduling and delivery, ordered UI projections, and pause, resume, and revocation controls.

2.2 · Trading Mission Runtime authority

What the durable runtime MAY do, and what it MUST NOT do

A harness turn is temporary. A trading mission is durable. The persistent services that remain active after an individual agent turn ends form the T3 Trading Mission Runtime inside the T3 server.

Runtime MAY

Durable, deterministic services

Persist mission, strategy, authority, watch, order, fill, and position state.
Maintain market and account subscriptions.
Evaluate simple typed watch predicates.
Schedule future reassessment events.
Reconcile local records with Hyperliquid.
Preserve exchange-native protective orders.
Queue a new harness turn.
Resume the mission's bound provider session.
Validate, sign, submit, and reconcile a typed action requested by the harness.
Perform explicitly defined fail-safe actions when a deterministic safety invariant is broken.

Runtime MUST NOT

Never become a second trading brain

The runtime must not independently:

Invent a new strategy.
Select a new discretionary entry.
Change directional bias.
Decide to scale into a position.
Decide to take profit.
Move a stop for strategic reasons.
Reverse a position.
Re-enter after a completed trade.
Interpret ambiguous user intent.
Replace the selected harness with a hidden rules engine.

2.3 · Correct runtime boundary

One execution boundary, three responsibilities

The harness remains the strategy actor. The T3 server remains the harness manager and execution boundary. Hyperliquid remains the canonical exchange-state authority.

T3 clientconversation · workspace · controls · projections

T3 server / execution environmentprovider & harness management · orchestration engine · trading mission runtime · persistence & event inbox · market watches & scheduling · deterministic authority & execution · Hyperliquid & Privy adapters

Selected harnessCodex · Claude · OpenCode

Hyperliquid / Privymarket & account truth · exchange actions · signing

Typed requests flow in; ordered pushes flow back out. Nothing in the harness reaches Hyperliquid or Privy directly, and nothing on the exchange reaches the harness except through T3's typed tool surface.

2.4 · Turn vs mission

Agent turn completion is not mission completion

These four concepts must remain distinct. Conflating them is the most common cause of incorrect autonomous-trading architecture.

Harness turn ended

One reasoning-and-tool-use cycle finished

The provider completed one reasoning-and-tool-use cycle. The mission is not over. The session is not necessarily closed.

Harness session available

The same thread can resume later

T3 can resume the same provider thread later, with preserved mission, strategy, authority, and tool-version context.

Trading mission active

T3 keeps monitoring and may wake the harness

T3 continues monitoring registered events and may wake the harness when a watch, timer, exchange update, or user message requires fresh judgment.

Execution environment running

The server process is available

The server process, network connection, subscriptions, timers, and workers are available. Without this, nothing runs.

POC autonomy is conditional. The POC remains autonomous after an agent turn ends only while the T3 execution environment continues running. It does not promise continuous operation while the host machine is powered off, asleep, disconnected, or the T3 server is stopped. Future always-on operation should run the same T3 server architecture in a remote execution environment — it should not introduce a separate trading control plane.

6.1–6.2 · Server composition

The fork preserves T3's shape and adds a trading extension

The fork should preserve T3's existing architectural shape: React clients communicate with a T3 server through typed RPC and ordered push events; the T3 server is the execution environment and main coordinator; provider adapters own provider-specific protocols; ProviderService provides cross-provider session start, resume, routing, and event streaming; provider-native events are normalized into the orchestration domain; queue-backed workers serialize long-running asynchronous flows; runtime receipts provide deterministic completion signals; contracts define the transport and domain boundary; and remote access changes how a client reaches a T3 server, not who owns runtime state. Trading extends these concepts rather than creating parallel infrastructure.

Existing T3 core (preserve)

Untouched orchestration spine

connection & environment runtime
provider registry & adapters
ProviderService
provider runtime ingestion
OrchestrationEngine
ProviderCommandReactor
RuntimeReceiptBus
ServerPushBus
persistence

Trading extension (add)

New services, same orchestration domain

TradingMissionService
TradingTurnCoordinator
TradingEventIngestion / TradingEventReactor
MarketDataGateway
MarketWatchRegistry
TradingScheduleService
TradingAuthorityService
TradingControlService
TradingToolRegistry
HyperliquidExecutionService
HyperliquidNonceCoordinator
OrderPositionReconciler
PrivyWalletService
TradingProjectionService

6.3 · Integration rule

Trading extends; it does not fork the runtime

The trading extension may add new domain events, commands, services, tools, projections, and UI surfaces. The constraint is not "do not modify any upstream file" — it is "do not build a second T3 inside T3."

Trading MAY add

Additive domain surface

New domain events.
New commands.
New services.
New tools.
New projections.
New UI surfaces.

Trading MUST NOT

Parallel infrastructure is forbidden

Replace ProviderService.
Start provider processes directly from trading code.
Create a second provider-session directory.
Create a second orchestration engine.
Bypass T3's runtime-event ingestion.
Send unordered UI events outside ServerPushBus.
Give provider adapters direct Hyperliquid or Privy access.
Put exchange credentials into provider prompts.

The integration rule, stated plainly. Every entry on the MUST NOT list is a way to accidentally build a second trading brain, a second control plane, or a second truth source inside the same process. Any one of them breaks the runtime boundary in §2.3 and the ownership boundary in §9.

9 · Domain ownership boundaries

Each layer owns a distinct set of decision rights

The architecture is only safe if every layer respects the next layer's decision rights. The table below assigns ownership; it does not describe cooperation. Layers cooperate constantly, but no layer silently absorbs another layer's decisions.

Layer	Owns
Selected harness Strategy actor	Market interpretation Strategy selection Discretionary sizing below authority limits Entry, scale, reduction, exit, and re-entry decisions Concise explanations Watch registration choices
T3 provider layer Harness manager	Provider instances Provider session start and recovery Thread routing Runtime event normalization Tool-session provisioning
T3 Trading Mission Runtime Durable infrastructure	Durable mission state Event inbox and scheduling Watch evaluation One-run-at-a-time coordination Deterministic validation Direct user risk-control commands Signing coordination Order submission and reconciliation UI projections
Hyperliquid Canonical truth	Canonical market metadata Account state Orders and fills Positions, margin, funding, and PnL
Privy Identity and signing infrastructure	Wallet provisioning Policy-constrained signing infrastructure

No layer may silently absorb another layer's decision rights.