> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/engineering-guide/01-system-overview.md). # System overview [Documentation home](/nytshift-docs/start-here/readme.md) ยท Next: [Architecture and data flow](/nytshift-docs/engineering-guide/02-architecture-and-data-flow.md) NYTSHIFT is AgentOps for perpetual markets: a governed operating layer where evidence can flow to humans and scoped external agents while capital authority moves through a narrow, typed and auditable path. The platform combines public market data, read-only portfolio context, deterministic PAPER, operator-issued agent tools, AEGIS policy and separately gated venue signers. ![Four NYTSHIFT operating layers: market truth, agent intent, AEGIS policy and capital memory converging under user-owned authority](https://365345826-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FD02RJbcs8ypn0hikgNUk%2Fuploads%2Fgit-blob-d8edfd6a44258c077627de2eef3c1ed2060b924e%2F01-capital-operating-system.png?alt=media) ## Names in the codebase | Name | Meaning | | --------------- | -------------------------------------------------------------------------------------------------- | | **NYTSHIFT** | Public product and brand | | **NIGHTSHIFT** | Historical namespace retained by packages, contracts, environment variables and policy identifiers | | **AEGIS** | Pure deterministic policy/risk engine; it is not the product name and not a model | | **Arcus** | Robinhood Chain-rooted perpetual venue rail | | **Lighter** | Public market-data rail plus local PAPER simulation; no Lighter signer authority | | **Hyperliquid** | Public data rail plus separately gated signer integration | Renaming the historical namespace is not a documentation cleanup. Contract names, environment variables, persisted schemas and policy IDs are compatibility surfaces. ## The core loop ```mermaid flowchart LR V[Venue and chain evidence] --> N[Strict normalization] N --> P[Consumer projections] P --> U[Terminal and API views] P --> A[AEGIS evaluation] G[User or durable agent mandate] --> I[Typed intent] I --> A A --> R[Human review or policy controller] R --> S[Separately gated signer] S --> X[Venue] X --> C[Authoritative reconciliation] C --> M[Portfolio and audit memory] M --> A ``` The critical design choice is the split between **information**, **policy** and **authority**. A model can create a typed proposal. It cannot create a signer capability. A valid proposal does not replace a fresh market read, account reconciliation, fee check, AEGIS verdict or user/policy authorization. The diagram describes the full architecture, not a generally active agent-to-signer path. MCP ends before venue execution. Hyperliquid testnet automation is separately gated, and no mainnet agent authority mode exists. ## Authority ladder | Level | Can do | Cannot do | | ----------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ | | Public research | Read normalized markets, books, candles, funding, public account and RHC identity evidence | Sign, submit, cancel, transfer or infer missing data | | Customer research | Add exact, consented account and portfolio context | Convert a linked wallet into execution authority | | Proposal | Register a strict thesis/intent envelope | Reach a signer or reserve capital by itself | | Paper | Simulate against fresh live books under an immutable local/server policy | Claim venue fills, queue position, fees, funding settlement or venue-exact liquidation behaviour | | Approval | Produce a short-lived, one-use reviewed action | Retry an unknown result or bypass fresh checks | | Testnet policy | Make one DPoP-bound attempt inside a durable Hyperliquid testnet policy | Edit policy, cancel arbitrarily, reuse a request ID or reach mainnet | | Mainnet | Architecture and gates exist | Disabled unless every independent release, legal, signer, canary and rehearsal gate is current | ## Product surfaces ### Public homepage Explains the AgentOps qualification model, the current capability boundary and the product's human-owned authority thesis. ### Robinhood Chain command deck Joins canonical Stock Token and ETF identities to reviewed Chainlink oracle identity and currently live perp context. A symbol match is never identity proof. Venue listing, oracle coverage, bridge evidence and execution capability remain separate columns of truth. ### Trading terminal Provides multi-venue discovery, exact-context charts, live books/trades, funding, technical studies, bounded public-account inspection, paper trading, explicit approval/live modes and build provenance. ### Customer capital workspace Uses verified Privy identity and exact linked-wallet evidence to expose portfolio, activity, performance and funding views. Venue capital domains are intentionally not summed into a fictional universal balance. ### Customer AgentOps workspace Inspects proposal-token mandate, symbols, limits, quota, expiry and authority. It does not currently issue, display or revoke MCP connection credentials. ### Operator Agent Command Center Issues expiring local MCP connections, binds exact tool/market/account scopes, exposes bounded connection activity and supports revocation. Hosted customer self-service connection issuance remains unavailable. ## What the system refuses to pretend * A ticker is not a canonical asset identity. * A midpoint is not a mark. * A retained value is not a fresh observation. * A provider ACK is not finality. * A login is not operator authority. * A wallet connection is not transaction consent. * A paper fill is not venue execution. * A model subscription is not a platform entitlement. * A configured service is not production readiness. * An unknown outcome is not permission to retry. ## Continue reading Read [Architecture and data flow](/nytshift-docs/engineering-guide/02-architecture-and-data-flow.md) for runtime ownership, or jump to [Trust and authority](/nytshift-docs/engineering-guide/03-trust-and-authority.md) if your first concern is the capital boundary. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://nytshift.gitbook.io/nytshift-docs/engineering-guide/01-system-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.