> 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/start-here/readme.md). # NYTSHIFT AgentOps documentation NYTSHIFT is **AgentOps for perpetual markets**: a governed operating layer where humans and external agents can work with source-labelled market context while mandates, evidence and capital authority remain explicitly separate. > **Prove an agent before it touches capital.** Use human PAPER in the customer workspace, or connect an external agent through operator-issued local Model Context Protocol (MCP) tools. NYTSHIFT gives each agent an exact, expiring scope and keeps PAPER simulation outside venue-order authority. AEGIS, NYTSHIFT's deterministic policy engine, applies declared rules at the boundary. Wider authority is never inferred from a model, a profitable run or a subscription tier. ## Start with the product truth | Capability | State and boundary | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Human PAPER workspace | **CURRENT.** Available in the customer workspace against fresh normalized books. It creates no venue order. | | External-agent PAPER | **GATED.** Local-only through a signed Agent Pro entitlement and platform-operator-issued MCP connection. This is not hosted self-service access. | | Agent market context and proposals | **GATED.** Source-labelled context and advisory proposals are available only inside an entitled, issued scope. | | Agent activity evidence | **GATED.** An entitled, issued credential can read bounded activity. It is only a partial recorder foundation. | | AEGIS | **CURRENT.** NYTSHIFT's deterministic policy engine currently resolves approved or rejected decisions. | | Human venue actions | **GATED.** Each venue uses its own signer, readiness, reconciliation and explicit authorization path. | | Hyperliquid testnet automation | **GATED.** Requires the signed Agent Pro automation add-on and a separate policy path. It is not an MCP execution tool. | | Mainnet agent authority | **UNAVAILABLE.** No current agent mode can grant itself mainnet execution authority. | | Unified Flight Recorder and Strategy Passport | **NEXT.** Human and agent PAPER evidence stores remain separate today. | | Public strategy marketplace | **VISION.** Public ranking, licensing or sales are not current capabilities. | [Read the complete current capability boundary](/nytshift-docs/agentops/current-capabilities.md). ## The qualification direction **Observe → Simulate → Record → Challenge → Qualify → Bound → Monitor → Revoke** This is the target product sequence, not a shipped end-to-end promotion system. The current release implements scoped context, separate human and agent PAPER surfaces, bounded activity, deterministic AEGIS decisions and independently gated authority paths. Unified strategy lineage, comparable qualification evidence and promotion receipts remain explicitly next. Under the target model, any material strategy change returns to qualification. PAPER cannot promote itself. An agent cannot widen its own tools, symbols, limits, expiry or authority class. ## Choose a path | You want to… | Start here | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Understand the AgentOps product | [AgentOps for perpetual markets](/nytshift-docs/agentops/agentops.md) → [Current capabilities](/nytshift-docs/agentops/current-capabilities.md) → [Qualification loop](/nytshift-docs/agentops/qualification-loop.md) | | Run or evaluate PAPER | [PAPER and evidence](/nytshift-docs/agentops/paper-and-evidence.md) → [Paper trading](/nytshift-docs/engineering-guide/05-paper-trading.md) | | Connect an external agent | [Bring Your Own Agent](/nytshift-docs/engineering-guide/06-bring-your-own-agent.md) → [Agent platform contract](/nytshift-docs/normative-design/agent-platform.md) | | Understand venues and authority | [Venues, accounts and authority](/nytshift-docs/agentops/venues-and-authority.md) → [Trust and authority](/nytshift-docs/engineering-guide/03-trust-and-authority.md) | | See what comes next | [Product horizon](/nytshift-docs/agentops/product-horizon.md) | | Build, review or operate the system | [System overview](/nytshift-docs/engineering-guide/01-system-overview.md) → [Architecture](/nytshift-docs/engineering-guide/02-architecture-and-data-flow.md) → [Production operations](/nytshift-docs/engineering-guide/12-production-operations.md) | ## One operating picture, separate sources of truth NYTSHIFT can project supported venue context into one workspace for humans and scoped agents. That does not merge collateral, balances, permissions or signer authority. An all-venues view is a derived projection. Each venue and account remains source-labelled, and a partial or stale input keeps the combined view partial or stale. AI participates in research, simulation and typed proposal formation. It does not receive private keys, sign transactions, submit venue orders through MCP, cancel, retry an unknown outcome or turn missing evidence into authority. ## Engineering reference The rest of this book preserves the technical and operational proof behind the product boundary: 1. **Guided book:** the system from market evidence to policy and authority. 2. **Architecture and decisions:** normative trust boundaries and compatibility contracts. 3. **Runbooks:** operator procedures for degraded states and sensitive workflows. 4. **Implementation ledger:** tickets and acceptance evidence. 5. **Generated contracts:** machine-checkable API and signer boundaries. The [table of contents](https://github.com/Nytshift/nytshift/tree/agent/nightshift-paper-db-live-readiness/docs/SUMMARY.md) keeps the product narrative first and the full engineering corpus available beneath it. Historical tickets remain accessible through the [implementation index](/nytshift-docs/implementation-ledger/tickets.md). ## Truth vocabulary | Term | Meaning in this book | | -------------- | --------------------------------------------------------------------------------------------- | | **Observed** | Source-attributed evidence exists for the stated scope and time. | | **Available** | The exact runtime evidence required by the contract exists now. | | **Configured** | A dependency has settings or assets; this does not establish readiness. | | **Ready** | The documented technical gate passed for an exact scope and evidence window. | | **Authorized** | A separate actor granted the exact action authority. Readiness alone never does. | | **Unknown** | A capital action may or may not have reached a venue and must be reconciled before any retry. | Missing, partial, stale, ambiguous and unknown states remain distinct throughout the product and this documentation. --- # 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/start-here/readme.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.