ASNOMIC · Agent Specification

ASNOMIC for Agents

This is an HTML rendering of ASNOMIC's canonical agent skill. The canonical machine-readable Markdown file is https://asnomic.com/asnomic-skill.md.

# ASNOMIC — Bounded Investigation and Persistent Market Observation V1

Status: Private Beta. Bounded general research, registered scientific instruments,
principal-approved persistent market observation, and gated External Live Observations are
distinct supported planes. External-paid execution, external-commercial monitoring on market data, broker
execution, GPU execution and exact frozen neural-model inference are not enabled.

Private Beta capacity is 30 code-gated seats. New admission requires a valid invitation code,
verified Google sign-in, the independent admission gate to be open and an available seat. Returning
members can sign in when capacity is full. Google sign-in alone does not provision monitoring or
grant promotional credits. Inspect `describe_asnomic.monitoring.admission` for current status.
Contact [ASNOMIC support](mailto:support.asnomic@gmail.com) to request access or report an issue.

## Orientation and capability map

**ASNOMIC is a persistent environment for bounded empirical investigation and approved prospective
observation.** Use its available instruments to investigate a question, preserve the method and
evidence, arrange supported recurring checks, and revisit results across sessions. Bring relevant
user context and other authorized tools; use ASNOMIC only for the parts its current contracts
support. Examples are compositions, not an exhaustive question whitelist or a promise of universal
data support.

**You and your AI can form the thesis. ASNOMIC keeps watching the evidence.** The human supplies
objectives and constraints, grants data access, approves applicable operations and makes
consequential decisions. The host agent identifies a bounded question, inspects current
capabilities, invokes supported methods, attributes external work and interprets limitations.
ASNOMIC executes named operations, maintains their records and persists approved checks where
implemented. The data, authority and runtime contracts—not the agent's fluency—decide what can run.

| Plane | Start with | What it currently provides | Boundary |
| --- | --- | --- | --- |
| General workspace research | `get_research_capabilities` | Durable AgentID-owned numeric CSV artifacts; column summaries; one-feature ridge regression with an ordered 80/20 holdout | User-declared data; no protected `MONITOR` qualification or live input refresh |
| Registered scientific work | `list_training_instruments` | Curated FIT exposures, managed classic CPU regressors, provenance and one protected server-side aggregate evaluation | General uploads cannot enter the protected corpus; `MONITOR` rows and SEALED data remain unavailable |
| Persistent live monitoring | `monitor_capabilities` | Bounded market methods, preview, exact human approval, prospective runs, lineage, retrieval, cancellation and qualified delivery | Only current runtime-qualified sources/cadences; no trading, arbitrary code or automatic agent resumption |
| External Live Observations | `external_live_capabilities` | Discoverable platform-neutral scalar capability; agent-prepared inert drafts; event-driven persistent evidence; explicit freshness and gaps | Entitlement plus explicit human portal approval controls source, write-only credential and activation; producer correctness is not independently verified |
| Public fit and trust | This guide, `describe_asnomic`, Privacy, Terms and Acceptable Use | Capabilities, current limits and access information before connection | Public review is not a runtime test or safety certification |

Ask your AI to review ASNOMIC's public information first. **No ASNOMIC signup is needed to assess
fit. Connect only when there is a useful supported task you want to run.** Copy and complete the
bracketed context below; a browsing-enabled assistant may need web access:

> I use an AI assistant for [my workflow], and I repeatedly need to check [specific task]. Safely
> review asnomic.com and its public agent guide. Explain what could help, what is unsupported, and
> what you could not verify. Do not create an account or run anything.

A bounded answer may be one computation, one supported monitor, a conditional composition, a
request for material missing data, or an honest no-fit conclusion. Success is accurate
understanding and useful action when a fit exists—not endorsing ASNOMIC by default. Negative or
inconclusive results remain valid evidence.

## Operate: public authorities and transport

- Root: `https://asnomic.com/`
- Machine discovery: `https://asnomic.com/.well-known/asnomic`
- Canonical skill: `https://asnomic.com/asnomic-skill.md`
- MCP Streamable HTTP: `https://asnomic.com/mcp`
- Policies: [Privacy](https://asnomic.com/privacy), [Terms](https://asnomic.com/terms),
  [Acceptable Use](https://asnomic.com/acceptable-use)

Use an MCP client capable of an arbitrary HTTPS endpoint and an `Authorization` header.
Initialize the MCP connection. When OAuth is enabled, `tools/list` requires authentication;
native agents can still call the public onboarding tools before authenticating. After authentication,
use `tools/list` to inspect live schemas. Public onboarding
tools include `describe_asnomic`, `get_pricing_and_access_policy`,
`begin_agent_registration`, `complete_agent_registration`, `begin_agent_auth`, and
`complete_agent_auth`. Research calls require a bearer token. Native Ed25519 access does not require a browser login.
OAuth is additive: when discovery reports `oauth.enabled=true`, compatible remote MCP clients
can use authorization code + PKCE S256 with Google browser sign-in and explicit ASNOMIC consent.
The Google request uses only the OpenID identity and verified-email scopes (`openid email`); it does
not request Gmail or Google Drive API access.
The separate `asnomic:read`/`asnomic:execute` consent applies only to ASNOMIC resources.
Never copy a private key or bearer/refresh token into chat. Claude custom-connector compatibility
is **UNVERIFIED** until the documented real connector qualification passes; generic tests are not
that evidence. Google configuration and deployment are required before browser access is live.

OAuth metadata: `/.well-known/oauth-protected-resource/mcp` and
`/.well-known/oauth-authorization-server`. Bind requests to resource `https://asnomic.com/mcp`.
Scopes are `asnomic:read` and `asnomic:execute`; both remain constrained by AgentID entitlements.
Access tokens last ten minutes. Refresh tokens rotate with replay revoking the grant; the grant
has a fixed 30-day expiry and a 1,024-exchange cap. Reauthorize after either bound. Revocation at
`/oauth/grants` immediately rejects access and refresh. Disconnect behavior in a specific client
must be tested; if it only forgets credentials, explicitly revoke through ASNOMIC as well.

| Access/discovery tool | Purpose and evidence | Side effect or authority |
| --- | --- | --- |
| `describe_asnomic` | Public product, research, monitoring, status and canonical-link discovery | Read-only; no account or signup required |
| `get_pricing_and_access_policy` | Versioned research entitlement and paid-execution status | Read-only; no quote, purchase or spend |
| `begin_agent_registration` / `complete_agent_registration` | Prove possession of a raw Ed25519 public key and create a persistent AgentID | Completion creates identity/entitlement state; private key remains local |
| `begin_agent_auth` / `complete_agent_auth` | Exchange a single-use signed challenge for a 30-minute bearer token | Creates short-lived access authority; never expose the token in chat |
| `get_agent_profile` / `get_agent_entitlement` | Read the authenticated identity, usage, reservations and limits | Read-only and ownership-bound |
| `create_human_claim_request` | Optional short-lived supervision-acknowledgement link | Creates claim state; no compute, connection, entitlement or monitoring approval |
| `submit_product_feedback` | Record a bounded maintainer-only feature request, bug or friction report | Authenticated write; costs no research unit and promises no delivery date |

For an existing native AgentID, call `create_oauth_account_link` while natively authenticated,
open its short-lived link, sign in with Google and confirm that exact AgentID before connecting.
Unlinked first-time Google users explicitly create an OAuth-controlled AgentID at consent.
Returning to the same linked Google account returns to the same AgentID, regardless of chat.
Reconnect with the same authenticated AgentID to inspect persistent authority in later sessions.
Linking an additional AgentID requires operator provisioning and is not self-service. Do not create
a second identity to bypass limits.

### Establish and preserve an AgentIdentity

1. Generate an Ed25519 keypair locally, or reuse your existing ASNOMIC credential. Encode the
   raw 32-byte public key as base64url. Keep the private key outside prompts, logs, and ASNOMIC.
2. Call `begin_agent_registration(public_key=...)`. Sign the exact UTF-8 bytes of its
   `canonical_challenge`; do not reserialize, trim, or alter them. Encode the signature as
   base64url. Call `complete_agent_registration` with `registration_id`, `public_key`, and
   `signature` from this exchange.
3. Preserve the returned `agt_…` AgentIdentity, `cred_…` credential identifier, and local private
   key across sessions. Cryptographic possession is not verification of a unique human. Do not
   create identities to evade limits. Losing a key does not transfer its history to a new identity.
4. Call `begin_agent_auth(agent_id=...)`, sign its exact canonical challenge, then call
   `complete_agent_auth(auth_id=..., signature=...)`. Send `Authorization: Bearer <access_token>`
   on every protected MCP request. The token expires after 30 minutes; refresh by a new signed
   challenge. Challenges are expiring and single-use.
5. Call `get_agent_profile` and `get_agent_entitlement` to inspect your own identity, current
   allowance, reservations, limits, and qualification rules before compute.

Never submit private keys, bearer or producer tokens, broker credentials, payment credentials, or arbitrary
executable code as tool arguments. The older short-lived human claim supports supervision acknowledgement only. Google OAuth
account linking is a separate explicit flow; commercial execution remains disabled.

## Compose a bounded question into attributable evidence

### Discover context before choosing a method

Identify the user's question, the decision it may inform, already-authorized context, relevant
observation frequency and any missing input that would change the method. Do not force a long
questionnaire when this context is already present. Inspect the current tool list and capability
response before promising execution; do not map every question to a threshold or reject a useful
subtask solely because ASNOMIC lacks a native connector.

Separate the workflow into data access, normalization or preprocessing, computation, recorded
evidence, ongoing refresh, persistent checks, delivery and later interpretation. Name the owner of
each step:

- The human supplies objectives and constraints, grants access, approves monitor activation and
  makes consequential decisions. Approval to observe is not authority to trade, expand a budget or
  change another system.
- The host agent understands context, selects supported methods, invokes tools and interprets
  results without inventing measurements, permissions or conclusions.
- External authorized tools may supply portfolio context, preprocessing or calculations. Retain
  their provenance and limits: storing an external result in ASNOMIC does not mean ASNOMIC computed
  or verified it.
- ASNOMIC executes only its named contracts and preserves the resulting authorities. Data visible
  to the host agent is not automatically an accepted ASNOMIC dataset or unattended runtime input.

Prefer the simplest adequate supported method. When a step is unsupported, name the missing
operation, input or authority; offer only a genuinely useful supported subtask; state what would be
needed for the remaining claim. Never substitute a weak proxy silently. “This part is supported;
this external dependency is required; the remaining claim cannot currently be established” and an
honest no-fit assessment are valid outcomes.

### Preserve an evidence contract using existing records

Use available artifact, method, run and lineage fields to retain:

- the question and limited claim being examined;
- input source/identity, units, timestamps, relevant versions and freshness;
- method, parameters/windows, baseline or comparator and applicable approval evidence;
- actual outputs and the rule that produced a condition state;
- assumptions, excluded costs or variables, missing data and interpretation limits; and
- evidence that would justify review, a prospective revision or a request for more input.

If an item has no ASNOMIC field, retain it as host-agent context and say so. Do not invent stored
fields, immutable guarantees or provenance. A historical/event study is not an execution backtest;
an ordered split is not proof against leakage; schema-valid data may still be scientifically
inappropriate; and a deterministic threshold is not a calibrated significance result. Never use a
disclosed protected result to select a new winner and still call the result untouched confirmation.

### Keep four data/authority planes separate

1. **General workspace research** accepts bounded user-declared numeric CSV and preserves summary
   or small-regression artifacts. It does not import data into the curated scientific corpus or
   activate a live method.
2. **Protected scientific `MONITOR` evaluation** is a server-side aggregate evaluation split for
   curated FIT-trained classic models. `MONITOR` here is not the scheduled monitoring service;
   protected rows, labels, matrices and row-level results remain unavailable.
3. **Persistent live monitoring** runs an immutable, quoted and approved market method on supported
   provider data. A general artifact cannot be promoted into this runtime. Preview does not compile
   research into a monitor, and an observed condition change does not establish causality,
   profitability, safety or strategy failure.
4. **External Live Observations** accept authenticated, versioned scalar measurements only for an
   explicitly entitled principal. The producer computes upstream; ASNOMIC validates the bounded
   contract, preserves source and receipt evidence, and evaluates the human-approved method. This
   does not make the producer's calculation, mapping, metadata, or provenance ASNOMIC-verified.

### Input freshness and later-agent behaviour

**A snapshot visible in the conversation is not a live input feed.** Treat a workspace upload or
portfolio export as static historical evidence dated to its source timestamp. While an agent is
connected, it may obtain an authorized refresh externally and upload a new accepted artifact, with
new provenance; ASNOMIC does not refresh that external context itself. Unattended ingestion is
limited to the market-data path and exact cadences reported runtime-qualified by
`monitor_capabilities`, plus explicitly entitled External Live Observation sources. The generic
external contract is a bounded scalar input path, not an arbitrary telemetry stream or universal
adapter. Its MT5 reference adapter reads current portfolio telemetry from a local
already-authenticated terminal; it is not a broker execution connection. Missing, partial,
unsupported, or stale live data produces `DATA_UNAVAILABLE`, not an invented value, zero, false
condition, or silent `NO_CHANGE`.

Distinguish these outcomes:

1. **Evidence retained:** a later authenticated session can list/get records it owns.
2. **Notification delivered:** an ACTIVE monitor may send the existing qualified notification when
   its delivery contract and destination are satisfied; SHADOW suppresses customer trigger delivery.
3. **Agent resumed:** not provided or verified. A stored record, email, callback or MCP session does
   not automatically start another LLM task. A compatible external runtime could consume an
   available event only under its own integration, authorization and budget.

An evidence-bearing change should be explained with the existing observation/method identity,
measurement time and freshness, evaluated condition, state reason and retrieval location. ASNOMIC
persists approved computation; it is not an always-thinking agent. Later reasoning, external calls,
spending and consequential action require their own authority.

**The investigation pattern can apply beyond finance. Current execution remains limited to the
inputs, operations, sources, cadences and delivery mechanisms ASNOMIC actually supports.** A
continuous source can conceptually become timestamped observations, but this does not advertise
streaming transport, arbitrary telemetry ingestion, millisecond execution or universal storage.

## External Live Observations V0

Use this plane when an external system already computes bounded scalar measurements. Start with
`external_live_capabilities`, even when the principal is not entitled. It explicitly reports
whether the capability is available, inspect-capable, prepare-capable, entitlement-blocked,
principal-approval-blocked, or account-blocked, plus owned drafts, sources, immutable metric
versions, freshness, monitor state, and evidence. It returns no producer secret and creates
nothing. `external_live_prepare_monitor(preparation_spec)` may save an inert, platform-neutral
`EXTERNAL_LIVE_MONITOR_PREPARATION_V0` draft with a generic source template, one to four versioned
metric definitions, exact conditions, `ALL`/`ANY` composition, dwell, and cooldown. Repeating the
same canonical draft is idempotent. `external_live_prepared_monitor(prepared_monitor_id)` reads its
state. Preparation creates no source, credential, active monitor, spend, or external action.

An entitled human principal must inspect the frozen draft hash and explicitly choose **Approve and
activate** in `/portal`. Only that portal action atomically creates the source and metric versions,
freezes the actual method hash, activates the persistent monitor, and returns the source-scoped
write credential once. No MCP tool can activate a draft. For an already-created owned source,
`external_live_monitor_preview(source_id, method_spec)` validates exact metric versions and returns
the canonical method hash without creating authority. Manual source/metric setup, credential
rotation/revocation, monitor disablement, and every activation remain human portal controls.

Prepared draft example (generic reinforcing signals; the names describe producer-owned
methodology, not ASNOMIC-verified facts):

```json
{
  "schema_version": "EXTERNAL_LIVE_MONITOR_PREPARATION_V0",
  "source": {"name": "Independent risk signal producer", "source_type": "CUSTOM_SCALAR_V0"},
  "metrics": [
    {"alias": "trend_risk", "definition": {"metric_key": "trend_risk", "name": "Trend risk", "description": "Producer-computed versioned trend risk score.", "value_type": "DECIMAL", "unit": "UNITLESS", "stale_after_seconds": 300}},
    {"alias": "liquidity_risk", "definition": {"metric_key": "liquidity_risk", "name": "Liquidity risk", "description": "Producer-computed versioned liquidity risk score.", "value_type": "DECIMAL", "unit": "UNITLESS", "stale_after_seconds": 300}},
    {"alias": "concentration_risk", "definition": {"metric_key": "concentration_risk", "name": "Concentration risk", "description": "Producer-computed versioned concentration risk score.", "value_type": "DECIMAL", "unit": "UNITLESS", "stale_after_seconds": 300}},
    {"alias": "sample_reliable", "definition": {"metric_key": "sample_reliable", "name": "Sample reliable", "description": "Producer emits 1 only when its documented sample rule is satisfied.", "value_type": "DECIMAL", "unit": "UNITLESS", "stale_after_seconds": 300}}
  ],
  "conditions": [
    {"condition_id": "trend_high", "metric": "trend_risk", "comparator": "GTE", "right": "10", "persistence": 2},
    {"condition_id": "liquidity_high", "metric": "liquidity_risk", "comparator": "GTE", "right": "10", "persistence": 2},
    {"condition_id": "concentration_high", "metric": "concentration_risk", "comparator": "GTE", "right": "10", "persistence": 2},
    {"condition_id": "sample_ok", "metric": "sample_reliable", "comparator": "GTE", "right": "1", "persistence": 2}
  ],
  "logic": {"type": "ALL", "children": [
    {"type": "CONDITION_REF", "condition_id": "trend_high"},
    {"type": "CONDITION_REF", "condition_id": "liquidity_high"},
    {"type": "CONDITION_REF", "condition_id": "concentration_high"},
    {"type": "CONDITION_REF", "condition_id": "sample_ok"}
  ]},
  "alert_policy": {"cooldown_events": 0}
}
```

V0 metrics are `DECIMAL` only. Each immutable definition fixes a metric key, name, description,
explicit unit (use `UNITLESS` where appropriate), definition hash, and 30–86,400 second freshness
window. A method pins one to four exact definition IDs/hashes/types/units, one to twelve `LT`,
`LTE`, `GT`, or `GTE` conditions, per-condition persistence of 1–20 complete events, bounded
`ALL`/`ANY` logic, and a 0–100 complete-event cooldown. Decimal thresholds and observations are
finite strings, never JSON floats. There is no custom code, function, URL, transform, unit
conversion, join, interpolation, or unbounded label set.

When methodology, sample sufficiency, data quality, or a bounded dimension affects the decision,
encode it as an explicit versioned metric contract and condition. A generic reinforcing-signal
method can, for example, require three independently computed risk scores plus
`sample_reliable GTE 1`, with persistence on every condition. A fresh heartbeat with a missing or
stale contributor proves only that the producer is alive: the monitor is `DATA_UNAVAILABLE` and
cannot advance dwell. V0 supports bounded `ALL`/`ANY`, not arbitrary N-of-M voting; a producer that
owns a 3-of-4 methodology can publish its versioned composite scalar rather than asking ASNOMIC to
run a second rules engine.

Each `EXTERNAL_LIVE_OBSERVATION_V0` carries source ID, metric-definition ID, producer-chosen
observation ID, timezone-aware source time, decimal value, and optional bounded producer reference.
ASNOMIC adds receipt time and canonical payload hash. Exact duplicate identities are idempotent;
conflicting identities or equal source times with different content fail; late observations remain
evidence but cannot replace current state or evaluate. Public observations more than two minutes in
the future or seven days old fail. Source-scoped producer credentials are shown only on
create/rotate and stored as digests. They authorize observation/heartbeat writes only—never reads,
MCP, source/method creation, monitor activation, credits, or another source.
Blocking a principal cancels its external monitors and revokes active producer credentials;
unblocking does not restore those secrets, so the principal must rotate before resuming.

An accepted current event evaluates once using the latest observation for every referenced metric.
Every input retains its own source and receipt time; no synchronized timestamp is fabricated.
Absent, stale, disabled, version-incompatible, or otherwise unavailable inputs produce a finalized
`DATA_UNAVAILABLE` run and do not advance or reset persistence. A heartbeat proves producer
liveness but never refreshes an old metric. A complete false-to-true persisted transition creates
one alert; continued true events preserve evidence without alert spam; a complete false event
rearms. Inspect the exact metric versions, observations, values, units, timestamps, source,
acceptance state, evidence references, condition state, and prior state before interpreting an
alert.

External measurements are customer-provided facts. Do not say ASNOMIC independently verified the
upstream data, calculation, permissions, or causal meaning. Do not publish producer secrets or use
a credential for a source you are not authorized to operate. General workspace uploads cannot be
promoted into this plane, and the plane is not a webhook marketplace, remote compute service,
database, document connector, or automatic action channel.

### MT5 read-only portfolio reference adapter

`MT5_READONLY_BETA` is an additional entitlement layered on External Live Observations. A local
Windows bridge attaches to an already authenticated MetaTrader 5 terminal and uses only
`initialize`, `version`, `account_info`, `positions_get`, `symbol_info`, `order_calc_profit`,
`last_error`, and `shutdown`. `order_calc_profit` is calculation-only. The bridge accepts only its
ASNOMIC connection ID and write-only producer secret; never request, store, or transmit a broker
login or password. It has no order, order-send, modification, close, pending-order, deal-history,
or strategy-control path.

The adapter retains exact `MT5_PORTFOLIO_SNAPSHOT_V1` open-position evidence: account currency,
positive equity, BUY/SELL, lots, prices, optional stop, magic number, position time, and explicit
symbol metadata. Supported symbol metadata must contain base currency, profit currency, and
positive terminal-provided contract size. Incomplete metadata is `UNSUPPORTED`, with null fields
and a reason; never guess it. Stop risk uses terminal-returned account-currency P&L from
`order_calc_profit`; a missing stop is `MISSING_STOP`, a failed calculation is `UNAVAILABLE`, and
neither may be treated as zero. The server accepts at most 200 positions and rejects snapshots more
than two minutes in the future or 24 hours old.

The principal maps exact magic numbers to human-named modules. Magic numbers are canonical signed
64-bit integer strings on the wire and in views, including values above JavaScript's exact-integer
range; numeric JSON values, leading zeroes, and out-of-range identifiers fail closed. Native
exposure uses BUY=+1 and
SELL=-1: base leg `sign × lots × contract_size`, profit/quote leg
`-sign × lots × contract_size × current_price`. V0 evaluates USD and XAU, nets positions within a
module and factor first, and only then groups distinct explicitly mapped modules with non-zero
same-direction exposure. Opposing directions do not form a shared same-direction claim. Unmapped
positions remain visible and make the relevant derived input unavailable; they are not silently
omitted to produce a non-breach.

An `MT5_SHARED_EXPOSURE_V1` rule explicitly states factor (`USD`/`XAU`), unit
(`NATIVE_FACTOR`, `ACCOUNT_CURRENCY_STOP_RISK`, or `EQUITY_PERCENT_STOP_RISK`), two to twenty
required mapped modules, optional per-module minimum, combined threshold, and one to ten snapshot
persistence. ASNOMIC supplies no financial threshold default. Risk views require complete
terminal-calculated inputs; otherwise the derived metric is unavailable. A change in terminal
account currency also makes an existing account-currency metric version unavailable rather than
relabeling its unit. A trusted observation
reference links each generic run and alert back to the retained snapshot, exact contributor
modules/positions, unsupported inputs, calculation status, threshold, raw/persistent state, and
previous state.

The bridge transmits only to an HTTPS origin, polls every 30 seconds, submits changed portfolio
content, and after a successful
unchanged poll heartbeats at least every 60 seconds. This adapter-specific heartbeat attests that
the retained canonical portfolio fingerprint is unchanged and can extend its derived-metric
freshness; a generic producer heartbeat cannot. The bridge retries with exponential delay capped at
60 seconds. After 180 seconds without a
snapshot or heartbeat the connection becomes stale and rules record one `DATA_UNAVAILABLE`
transition; recovery requires a valid current snapshot. Rotation immediately invalidates the prior
producer secret. Revocation stops the connection and dependent rules while retaining history.

Interpretation boundary: shared factor exposure is evidence of overlap, not proof of
diversification failure, portfolio unsafety, expected loss, or a reason to disable or trade a
strategy. V0 excludes history/pending orders, unsupported CFDs, inferred contract models, guessed
FX conversions, optimization, correlation/causal claims, stress/slippage models, broker execution,
automatic trading, order changes, and strategy control.

## Persistent Private Beta market observers

Use monitoring when a decision spans time beyond one chat and its evidence can be represented by
the bounded language below. An authenticated agent defines the method; ASNOMIC owns canonical
semantics, prospective scheduling, completed-observation authority, durable state, settlement,
and delivery. The resulting monitor belongs to the principal rather than the originating chat,
model provider, or AgentID.

#### Capability and serviceability contract

Always begin with `monitor_capabilities`. Schema support and live runtime support are different:

```text
RUNTIME_QUALIFIED for INTERNAL_BETA
- `EQUITY_30M`
- `CRYPTO_30M`
- `EQUITY_1D_CLOSE`

DESIGN_SUPPORTED
- a valid DSL/cadence combination that is not yet live-qualified
```

Preview may succeed for `DESIGN_SUPPORTED`; activation must fail until the exact market/cadence is
`RUNTIME_QUALIFIED`. Do not infer live availability from an enum or tool schema. External-paid
runtime and `EXTERNAL_COMMERCIAL` data use are disabled even for the three qualified cadences.

The exact public monitoring tool names are `monitor_capabilities`, `monitor_preview`,
`monitor_activate`, `monitor_get`, `monitor_list`, `monitor_branch`, `monitor_revise`,
`monitor_cancel`, and `monitor_delivery_status`.

Their operating contracts are:

- `monitor_capabilities(session_id?, task_id?)` reads the live language, cadence, lineage,
  delivery, funding, and Beta limits. It does not quote, reserve, activate, settle, or load market
  data. Call it again after a capability error instead of guessing.
- `monitor_preview(method_spec, duration_minutes, mode, client_plan_ref?, session_id?, task_id?)`
  validates and canonicalizes a `MONITOR_METHOD_SPEC_V1`, derives its authoritative method hash,
  data/warmup needs and maximum execution count, and creates an expiring OPEN quote plus exact
  pending approval URL. It creates no method, monitor, reservation, acquisition, activation,
  settlement, or delivery. Preview costs zero credits and is safe to repeat, although a repeat may
  create another quote. Preserve the chosen quote rather than approving one and activating another.
- `monitor_activate(quote_id, approval_id, method_spec, duration_minutes, mode,
  activation_idempotency_key, client_plan_ref?, scope="INTERNAL_BETA", session_id?, task_id?)`
  creates one immutable method, reservation, runtime activation, and monitor only after exact human
  approval. It settles the activation base once. Reuse the same stable idempotency key when retrying
  the same activation; never generate a fresh key after a timeout. Common failures are
  `HUMAN_APPROVAL_REQUIRED`, `HUMAN_APPROVAL_MISMATCH`, `METHOD_HASH_MISMATCH`, `QUOTE_EXPIRED`,
  `DESIGN_SUPPORTED_NOT_RUNTIME_QUALIFIED`, `INSUFFICIENT_PROMOTIONAL_CREDITS`,
  `DELIVERY_DESTINATION_MISSING`, and `EXTERNAL_PAID_RUNTIME_DISABLED`.
- `monitor_get(monitor_id, session_id?, task_id?)` reads one principal-owned monitor: immutable
  method/lineage, state, run history, credit reservation/settlement, delivery summary, and
  `client_plan_ref`. It does not execute or settle. `MONITOR_NOT_FOUND` and `OWNERSHIP_DENIED` must
  not be worked around.
- `monitor_list(status?, mode?, instrument?, client_plan_ref?, active_only?, cursor?, limit?,
  session_id?, task_id?)` reads a bounded, paginated list owned by the current principal. Use the
  returned cursor unchanged. A plan reference filters related independent monitors but grants no
  authority. Invalid limits/cursors return `MONITOR_LIST_INVALID`.
- `monitor_branch(parent_monitor_id, quote_id, approval_id, method_spec, duration_minutes, mode,
  activation_idempotency_key, client_plan_ref?, session_id?, task_id?)` activates a separately
  quoted and approved child hypothesis while leaving the parent active and immutable. Branching is
  bounded to three direct children and depth two. Retry with the same activation idempotency key.
  `BRANCH_LIMIT_REACHED` is a hard policy denial.
- `monitor_revise(parent_monitor_id, quote_id, approval_id, method_spec, duration_minutes, mode,
  activation_idempotency_key, client_plan_ref?, session_id?, task_id?)` prospectively replaces a
  parent with a new quoted/approved method and preserves the parent's historical authority. Use it
  when the monitoring decision changes, not to edit an old run. Retry with the same key.
- `monitor_cancel(monitor_id, session_id?, task_id?)` idempotently makes a monitor terminal,
  cancels future work, preserves settled credits, and releases unused reservation authority once.
  Repeating cancel reads the same terminal outcome; it never erases history.
- `monitor_delivery_status(monitor_id?, session_id?, task_id?)` reads configured destination and
  bounded outbox health without revealing destination secrets or provider credentials. It never
  creates a market alert. Alert authority and operational delivery state are deliberately separate.

All protected calls require `asnomic:read` or `asnomic:execute` scope as declared by the live MCP
schema. Treat MCP `isError=true` as failure even when HTTP succeeds. Preserve `session_id` and
`task_id` only for attribution; neither changes ownership.

#### `MONITOR_METHOD_SPEC_V1`

A method declares one to four canonical instruments from one market class, one cadence, one to
twelve conditions, a complete `ALL`/`ANY` logic tree, and one alert policy. Aliases and condition
IDs are lowercase identifiers. Decimal thresholds are finite strings, not JSON binary floats.
Methods contain no URLs, code, functions, dynamic symbol lookup, broker actions, or missing-data
instructions.

Expression families:

- `SOURCE(instrument, field)` reads `CLOSE`, `VOLUME`, or `HIGH_LOW_RANGE_PCT`.
- `RETURN(instrument, bars)` computes `close[t] / close[t-bars] - 1`.
- `RELATIVE_RETURN(left_instrument, right_instrument, bars)` subtracts the benchmark return from
  the asset return over exactly aligned completed bars.
- `ROLLING_MEAN(expression, window)` averages the current and preceding complete expression values
  and preserves the nested value type.
- `DISTANCE_FROM_MEAN(instrument, field, window)` computes current divided by the rolling mean,
  minus one.
- `ROLLING_VOLATILITY(instrument, window)` computes non-annualized population deviation of the
  latest one-bar simple returns.
- `CORRELATION(left_instrument, right_instrument, window)` computes Pearson correlation over
  exactly aligned one-bar returns.
- `VOLUME_VS_MEAN(instrument, window)` divides current volume by the prior-only volume mean.
- `RANGE_EXPANSION(instrument, window)` divides current high-low-range percentage by its prior-only
  mean.

Comparators are `LT`, `LTE`, `GT`, `GTE`, `CROSSES_ABOVE`, and `CROSSES_BELOW`. A cross needs both
the previous and current valid comparison; the first available sample cannot cross. The right side
may be a same-type expression or a decimal string. Use `ALL` when every referenced condition is
required and `ANY` when any referenced condition is sufficient. There is no `NOT`, and every
declared condition must appear in the logic tree.

`persistence: {"consecutive_true": n}` requires 1–20 consecutive complete true evaluations.
False resets the counter. Missing data breaks continuity and makes the composed result unavailable.
The only trigger is `FALSE_TO_TRUE`; `rearm` is `WHEN_FALSE`; cooldown is 0–100 complete evaluation
intervals. A true state does not repeatedly alert, unavailable data does not rearm, and cooldown
does not advance on unavailable evaluations.

The canonical expression names are `SOURCE`, `RETURN`, `RELATIVE_RETURN`, `ROLLING_MEAN`,
`DISTANCE_FROM_MEAN`, `ROLLING_VOLATILITY`, `CORRELATION`, `VOLUME_VS_MEAN`, and
`RANGE_EXPANSION`.

Lookbacks and windows are completed bars, not wall-clock duration. Returns allow 1–500 bars;
rolling windows allow 2–500. Relationship expressions require identical observation timestamps.
ASNOMIC never forward-fills, interpolates, nearest-neighbor joins, or silently skips missing
scientific values. Incomplete history, zero denominators, and undefined correlation produce
`DATA_UNAVAILABLE`, not `NO_CHANGE`.

Example: XLF relative weakness versus SPY at the daily close:

```json
{
  "schema_version": "MONITOR_METHOD_SPEC_V1",
  "cadence": "EQUITY_1D_CLOSE",
  "instruments": [
    {"alias": "primary", "market": "US_EQUITY", "symbol": "XLF"},
    {"alias": "benchmark", "market": "US_EQUITY", "symbol": "SPY"}
  ],
  "conditions": [{
    "condition_id": "relative_weakness",
    "left": {"type": "RELATIVE_RETURN", "left_instrument": "primary",
      "right_instrument": "benchmark", "bars": 5},
    "comparator": "LT",
    "right": "-0.01",
    "persistence": {"consecutive_true": 2}
  }],
  "logic": {"type": "CONDITION_REF", "condition_id": "relative_weakness"},
  "alert_policy": {"trigger_on": "FALSE_TO_TRUE", "rearm": "WHEN_FALSE",
    "cooldown_intervals": 0}
}
```

Canonicalization sorts and normalizes the scientific document. The resulting method hash excludes
duration, mode, `client_plan_ref`, explanation, delivery destination, and other operational data.
Once activated, that hash and method are immutable. **Methods can evolve. History cannot.**

#### Approval, credits, and delivery

Preview is non-billable: it creates an OPEN quote but no reservation, activation, settlement, data
request, or notification. The quote binds the exact method hash, mode, duration, execution bound,
pricing version, scope, and maximum credits. The approval page binds the same principal, quote,
hash, maximum atomic credit units, duration, and `INTERNAL_BETA` scope. Only then may the agent call
`monitor_activate`.

Current internal-Beta activation uses promotional/test credits only. The published nominal relation
is 100 credits = US$10, but purchasing credits, external-paid settlement, and autonomous paid-agent
budgets are disabled. Do not present a preview as a purchase offer. Email delivery costs zero
credits. `ACTIVE` is eligible for configured customer delivery; `SHADOW` runs the same scientific
and settlement workflow but suppresses customer trigger delivery and may omit a destination.

Delivery is an operational projection of a separate durable alert authority. Provider retries use
one stable delivery identity and do not create another market fact. `monitor_delivery_status`
reports the safe state. SMTP remains unqualified. Resend is the intended live API transport; treat
it as live-qualified only when current public discovery explicitly reports that deployment status.

Every due slot ends in `NO_CHANGE`, `TRIGGERED`, `DATA_UNAVAILABLE`, `EXECUTION_FAILED`, or
`CANCELLED`. Only legitimate completed `NO_CHANGE` and `TRIGGERED` executions settle the quoted
execution amount. Retries, duplicates, data unavailability, and pre-evaluation failures are free.
Completed observations carry canonical fingerprints; raw provider payloads and tokens are not
customer authority.

## Worked examples and composition status

`SUPPORTED EXAMPLE` means the current exposed contract and local tests support the listed
operations; it does not mean this exact recipe was run against the deployed service.
`CONDITIONAL COMPOSITION` requires a named external input, tool or manual handoff.
`HYPOTHETICAL APPLICATION` explains the pattern only and is not an end-to-end product claim.

#### E1 — Bounded historical investigation — SUPPORTED EXAMPLE

- **Natural request:** “Using a compatible CSV of daily volatility and next-day returns, compare
  the available simple predictive model against its baseline on the documented chronological
  holdout. Preserve the method, results, and limitations, including a result that adds no
  predictive value.”
- **Required context/data:** at least ten already-aligned, finite numeric rows with distinct
  `daily_volatility` and `next_day_return` columns, source description and user-asserted row order.
  The user or external preprocessing owns timestamp alignment and any overlapping-target analysis.
- **Tools/dependencies:** `get_research_capabilities`; `create_research_workspace`;
  `upload_workspace_csv`; then `run_workspace_computation(workspace_id=..., dataset_id=...,
  operation="univariate_ridge_chronological_holdout", feature="daily_volatility",
  target="next_day_return", alpha=1.0)`; later list/get the artifact.
- **Intended evidence:** immutable dataset hash/provenance, one-feature coefficient/intercept,
  ordered first-80%/final-20% split, holdout MSE, training-mean baseline MSE and artifact lineage.
- **Does not establish:** verified chronology, independence, significance, causal prediction,
  trading performance, fees/slippage, protected evaluation or a live-monitor method. A worse or
  equal baseline comparison is useful negative evidence.
- **Persistence/refresh:** the artifact is durable for the owning AgentID. A newer CSV is a new
  dated artifact; ASNOMIC does not refresh this external input.
- **Approval/side effects:** upload and compute create artifacts; successful compute consumes one
  legacy research unit. They require authenticated execute authority, not monitor approval.
  This recipe is locally tested; a deployed end-to-end run was not performed for this guide.

#### E2 — Supported recurring relationship observation — SUPPORTED EXAMPLE

- **Natural request:** “Monitor the documented rolling relationship between two supported
  instruments. Use the chosen threshold and persistence rule, preserve dated observations, and
  explain the actual rule that produced a state change.”
- **Required context/data:** two canonical identifiers in one supported market, the user's chosen
  threshold/window/persistence and a cadence currently reported `RUNTIME_QUALIFIED`. XLF/SPY below
  is a synthetic local schema fixture; confirm current provider availability during preview/runtime.
- **Tools/dependencies:** `monitor_capabilities`; `monitor_preview`; browser approval of the exact
  quote; `monitor_activate` only after approval; then `monitor_get`/`monitor_list` and, for ACTIVE,
  `monitor_delivery_status`. The preview call uses `duration_minutes=43200`, `mode="SHADOW"` and the
  method below; SHADOW is chosen to suppress customer trigger delivery, not to avoid approval or
  settlement.

```json
{
  "schema_version": "MONITOR_METHOD_SPEC_V1",
  "cadence": "EQUITY_1D_CLOSE",
  "instruments": [
    {"alias": "left", "market": "US_EQUITY", "symbol": "XLF"},
    {"alias": "right", "market": "US_EQUITY", "symbol": "SPY"}
  ],
  "conditions": [{
    "condition_id": "relationship_weakened",
    "left": {"type": "CORRELATION", "left_instrument": "left",
      "right_instrument": "right", "window": 20},
    "comparator": "LT",
    "right": "0.75",
    "persistence": {"consecutive_true": 2}
  }],
  "logic": {"type": "CONDITION_REF", "condition_id": "relationship_weakened"},
  "alert_policy": {"trigger_on": "FALSE_TO_TRUE", "rearm": "WHEN_FALSE",
    "cooldown_intervals": 0}
}
```

- **Intended evidence:** canonical method/hash, quote/approval, aligned one-bar return correlation,
  dated completed observations, condition/composed state, unavailability reasons and lineage.
- **Does not establish:** price-level correlation, factor exposure, portfolio aggregation, a common
  economic failure mechanism, causality, strategy failure or profitable action.
- **Persistence/refresh:** only the qualified market provider path refreshes unattended inputs;
  missing or unaligned bars are unavailable, never zero correlation or `NO_CHANGE`.
- **Approval/side effects:** preview creates an OPEN zero-credit quote, not a monitor. Activation is
  a state-changing, promotional-credit-reserving operation requiring exact human approval and a
  stable idempotency key. The method fixture is locally schema-tested; no live run was made.

#### E3 — Branch and revisit a monitoring hypothesis — SUPPORTED EXAMPLE

- **Natural request:** “Review the evidence from my approved monitor. Propose a comparison between
  the current persistence rule and a more conservative alternative. Preserve the original method
  and its evidence; obtain the required approval before activating any new work. Later, compare
  what the methods actually observed.”
- **Required context/data:** owned parent monitor, comparable prospective input windows, the exact
  alternative rule and a disclosed reason for adaptive selection.
- **Tools/dependencies:** read with `monitor_get`; preview the changed spec with `monitor_preview`.
  After separate approval, `monitor_branch` activates a child and leaves the parent active.
  `monitor_revise` instead activates a new method and cancels the parent prospectively. Use branch,
  not revise, when contemporaneous comparison is required; SHADOW suppresses customer trigger
  delivery but still executes and settles.
- **Intended evidence:** distinct hashes, parent/root/relation lineage, independently dated runs,
  states, unavailable periods, settlements and delivery status where applicable.
- **Does not establish:** an expected result as observed, independence after adaptive selection,
  calibrated superiority, automatic tuning, safety or reduced risk.
- **Persistence/refresh:** comparison needs genuinely comparable runtime inputs/windows; historical
  runs remain attributable and are never recalculated under the child.
- **Approval/side effects:** preview is candidate-only. `monitor_branch` and `monitor_revise` are
  activation operations requiring new quote, approval, credits and stable idempotency keys.

#### E4 — Shared portfolio exposure — CONDITIONAL COMPOSITION

- **Natural request:** “Given my authorized portfolio context, module definitions, positions, and
  recorded results, investigate whether different modules are loading onto the same risk. Separate
  historical co-movement from current position exposure. Identify the calculations and missing
  inputs, and use available tools for supported checks against my predefined conditions.”
- **Required context/data:** an external authorized provider must supply module mapping, positions
  and direction, quantities/units, applicable instrument specifications, timestamps, account
  currency and module-level history. Do not request brokerage credentials.
- **Tools/dependencies:** when both external capabilities are active, the MT5 read-only reference
  adapter can retain current open-position snapshots, apply exact magic-number module mappings,
  calculate native USD/XAU legs from terminal metadata, and use terminal-calculated
  account-currency stop P&L. Call `external_live_capabilities` first; setup, mapping and activation
  remain human portal controls. A pair of runtime-supported instruments may separately use
  `CORRELATION` for historical one-bar return co-movement.
- **Intended evidence:** separately attributed current-exposure calculation, historical
  module-return relationship, scenario assumptions and any smaller supported ASNOMIC result.
- **Does not establish:** that quoted-in-USD assets have identical USD risk, that incompatible lot
  sizes can be summed, that diversification failed or that a module should be paused.
- **Persistence/refresh:** the local Windows bridge polls the already-authenticated terminal,
  submits changed content and bounded heartbeats, and makes stale gaps explicit. Without the exact
  entitlements, bridge, metadata, mapping and live process, the unattended use case is unsupported.
- **Approval/side effects:** the principal controls connection, mappings, rules, credential
  rotation and revocation. Producer writes and MT5 calculation calls do not grant trade control,
  and alert evidence never authorizes a broker or strategy action.

#### E5 — Software telemetry — HYPOTHETICAL APPLICATION

- **Natural request:** “Using timestamped request volume, latency, and error measurements,
  investigate whether a latency increase coincides with a change in workload. Compare a short-lived
  spike rule with a persistence-based rule and propose what should trigger another investigation.”
- **Required context/data and dependency:** an external authorized telemetry source, alignment and
  refresh path; no observability integration or arbitrary streaming input is implemented.
- **Intended evidence:** externally prepared compatible data might support separate bounded
  summaries or one-feature regression artifacts. Candidate persistent rules are conceptual unless
  a current live source contract supports them.
- **Does not establish:** multivariate analysis, root cause, production repair or end-to-end live
  monitoring. Any artifact/activation would retain normal write, usage and approval effects.

#### E6 — Website/business performance — HYPOTHETICAL APPLICATION

- **Natural request:** “Investigate whether a conversion decline remains after accounting for a
  change in traffic composition. Define evidence that would justify another review and compare
  candidate monitoring rules without replacing the original.”
- **Required context/data and dependency:** suitable counts and denominators, aligned segments,
  external preprocessing/segmentation, an appropriate method and refreshed inputs. ASNOMIC has no
  attribution, funnel-analytics, arbitrary-join or causal-inference integration.
- **Intended evidence:** a compatible bounded external dataset could be recorded and analyzed only
  within current univariate limits; prospective monitoring remains conceptual without a supported
  source. This does not explain any past campaign result. Normal artifact/activation authorities
  would still apply.

#### E7 — Energy use — HYPOTHETICAL APPLICATION

- **Natural request:** “Compare electricity usage with operating hours and the contextual
  measurements available. Investigate whether the recent increase is unusual under the chosen
  baseline, and propose a persistent condition that warrants a human review.”
- **Required context/data and dependency:** authorized timestamped measurements, compatible units,
  a suitable supported or externally computed baseline and an ongoing input path. No smart-meter
  integration exists.
- **Intended evidence:** compatible static numbers might support bounded workspace analysis; the
  monitoring pattern is conceptual without a supported live source.
- **Does not establish:** equipment fault diagnosis, unattended control or safety-critical
  suitability. Any real artifact/activation would require the ordinary scopes, units and approval.

#### Detailed fit boundaries

Good fit: a decision outlives one chat; repeated market observation is needed; the criteria fit the
current DSL; provenance/history matter; or the user wants persistence independent of conversation
and model provider.

Poor fit: a one-off factual market question; news, sentiment, earnings-event, or macro-event
monitoring; an unsupported cadence/market; immediate broker execution; automatic trading;
portfolio construction; or arbitrary-code strategy execution. Fail closed rather than inventing a
feature, proxy indicator, unavailable data, or unsupported runtime.

Monitoring is not a profit guarantee, investment-advice guarantee, broker interface, or trading
instruction. There is no arbitrary Python, arbitrary custom indicator, news/event monitoring,
external-paid settlement, external-commercial qualification, broker execution, or auto trading.

For a concrete blocked task, an authenticated agent may call `submit_product_feedback` with the
minimal non-sensitive context, category `feature_request`, and the unsupported operation. A
successful result means only that a maintainer record was created; it is not a roadmap commitment
or delivery date. If the user asks to stop an ASNOMIC monitor, call `monitor_cancel` for that owned
monitor. Cancellation stops future ASNOMIC work but does not stop a broker strategy, external agent
or unrelated system.

## Legacy research access uses engineering units, not monitoring credits

The 4→8→12 values below are legacy research-workflow engineering access units. They are separate
from the 300 promotional/test monitoring credits granted to a provisioned internal-Beta principal.
They do not convert in either direction and must never be presented as contradictory balances.

| Stage | Total free units unlocked / maximum |
| --- | --- |
| TRIAL | 4 / 12 |
| QUALIFIED | 8 / 12 |
| ESTABLISHED | 12 / 12 |

These totals are not replenishing balances. Consumed and reserved units reduce availability.
One each of FIT exposure creation, classic-view materialization, model training, and protected
evaluation consumes one engineering unit on successful completion. Read the live policy for
operation costs and your current stage limits; discovery and capability inspection do not
consume these compute units. Rate limits and data limits still apply.

A provenance-complete FIT exposure → training view → model → protected MONITOR evaluation
lineage can produce a QualifiedWorkEvent and unlock 8 total units. Two distinct qualifying
exposures unlock 12 total. This is attribution and access control, not a research-quality or
financial score. Qualification does not depend on outperforming or reporting a positive result.
Treat additional access as a consequence of valid work, not the research objective.

TRIAL bounds:

- At most 4 FIT episodes per exposure; explicitly set `episode_count` at or below 4. The
  private scientific schema's default of 225 is not the public TRIAL allowance.
- At most 128 eligible FIT origins in a materialized view.
- At most 10 metadata records per query and 300 MiB of FIT shard reads per UTC day.
- At most 1 protected evaluation per day and 1 concurrent compute operation.

An episode is one asset-specific temporal market sequence containing many market rows and
eligible history-120 origin positions. It is a research/diversity unit, not one market observation.
The protected MONITOR population contains 58,183 eligible origins. That population is distinct
from your bounded FIT training exposure; a four-episode limit does not mean four training rows.

## General research workspace

Call `get_research_capabilities` for the current bounded contract. This is separate from the
protected scientific plane and does not require an ASNOMIC model or an ASNOMIC-owned asset.

| Tool | Input and evidence | Side effect, authority and failure boundary |
| --- | --- | --- |
| `get_research_capabilities` | Current formats, limits, operations and external-model status | Read-only; authenticate; do not infer live input support |
| `create_research_workspace` | Name; returns durable AgentID-owned workspace metadata | Creates state; `asnomic:execute` for OAuth; maximum four workspaces |
| `list_research_workspaces` | No input; returns owned workspace summaries | Read-only; another AgentID cannot recover ownership by guessing an ID |
| `upload_workspace_csv` | Workspace, CSV text, source and description; returns immutable dataset artifact and hashes | Creates user-declared evidence; no fetch or compute; validation fails closed |
| `run_workspace_computation` | Workspace, dataset, allow-listed operation and bounded parameters; returns stored result/model/baseline evidence | Successful call consumes one legacy research unit; no protected evaluation or live activation |
| `list_workspace_artifacts` / `get_workspace_artifact` | Owned workspace and optional artifact ID; returns hash-checked lineage and payload | Read-only; integrity/ownership mismatch is an error, not missing evidence to reconstruct |
| `register_workspace_model` | HTTPS reference, immutable revision, SHA-256 and declared owned datasets | Creates reference-only lineage; no download, execution or ASNOMIC verification |
| `create_oauth_account_link` / `revoke_oauth_connection` | Native identity or owned grant | Mutates only connection authority; linking needs browser confirmation; revocation does not delete research history |

1. `create_research_workspace(name)` or `list_research_workspaces()` to reopen durable state.
2. `upload_workspace_csv(workspace_id, csv_text, source, description)` to introduce evidence.
   V1 accepts UTF-8 numeric CSV only: 128 KiB, 2,000 rows, 16 unique plain column headers;
   finite numeric cells within ±1e12; no missing values, expressions, executable code, or fetch.
   The exact source hash and declared provenance are retained; compute uses binary64 values.
3. `run_workspace_computation` supports `column_summary` and
   `univariate_ridge_chronological_holdout`. Each successful operation consumes one existing
   engineering usage unit. Regression uses one selected feature/target, at least ten rows,
   first 80% training and final 20% evaluation, alpha from 0 to 1e6. User row order is preserved;
   timestamps, causal ordering and independence are not verified. Coefficients, holdout MSE,
   baseline MSE, inputs and hashes are preserved, including adverse results.
4. `list_workspace_artifacts` and `get_workspace_artifact` recover those results in a later chat.

There are at most four workspaces per AgentID, 32 artifacts per workspace, and 512 KiB of serialized
agent workspace state. This is a small research foundation, not unrestricted compute or storage.
Workspaces use durable Firestore in production; the memory store is for local tests only.
Workspace results never unlock scientific qualification or modify FIT/MONITOR/sealed authorities.
General holdout results are not protected MONITOR results, trading evidence or significance tests.

`register_workspace_model` records external model/artifact/provider references with provider,
HTTPS reference, immutable revision, content SHA-256, declared input datasets, identity/workspace
and `runtime=reference_only`. These values are user-declared until an adapter verifies them.
Hugging Face is adapter-ready for references only. No downloads, remote code, model execution,
GPU, third-party inference, arbitrary shell or unbounded network access is implemented.
Agent-created workspace regression models use the same provider-neutral model-source contract.

## ASNOMIC scientific workflow and its limits

The scientific tool family is registered and protected separately from general workspace data.
Read operations expose metadata or managed provenance; compute operations are entitlement-bound and
consume one legacy research unit only on successful completion.

| Tool | Purpose and evidence | Side effect, authority and significant limit |
| --- | --- | --- |
| `health` | Private runtime version/CPU-first health metadata | Read-only operational metadata; not uptime or scientific evidence |
| `list_training_instruments`, `describe_training_instrument`, `list_training_assets`, `get_training_instrument_provenance` | Discover the curated corpus, assets, geometry, access classes and serving lineage | Read-only; parent is provenance-only and protected/SEALED data remains inaccessible |
| `query_episode_metadata` | Bounded FIT/MONITOR episode metadata query | Read-only; returns no shard contents, targets or matrices |
| `create_training_exposure` | Deterministic bounded FIT selection and managed manifest | Creates immutable exposure; explicit seed/epoch/count; TRIAL limits apply; no `MONITOR` selection |
| `get_training_exposure_manifest` | Recover managed exposure identity, distribution and required shard bytes | Read-only; selected origin identities remain hidden |
| `materialize_training_exposure` | Create one managed classic view for an allowed target/transform | Creates an artifact and consumes a unit on success; no arbitrary tensor export |
| `list_classic_algorithms` | Discover Ridge, ElasticNet, Random Forest and HistGradientBoosting specifications | Read-only; advertised hyperparameter bounds remain authoritative |
| `train_classic_model`, `describe_classic_model` | Train an allow-listed CPU regressor; recover its FIT view, seed and model lineage | Training creates an artifact and consumes a unit on success; no GPU/custom code |
| `evaluate_classic_model_on_monitor` | One protected server-side evaluation with aggregate metrics and evaluation identity | Creates protected result and consumes a unit on success; repeat blocked; no rows/labels/per-row predictions |
| `list_model_instruments`, `describe_model_instrument` | Discover curated frozen-model provenance and availability | Read-only; availability must be inspected before inference |
| `run_world_model_inference`, `run_opportunity_inference` | Request exact curated inference for a FIT origin | Currently fail closed because runtime authority is unavailable; no result may be invented |
| `get_authority_provenance` | Recover known managed authority lineage | Read-only; unknown IDs fail rather than fabricate lineage |
| `telemetry_snapshot` | Bounded object-read/cache telemetry for the current runtime | Read-only operational telemetry; not a research finding or service-level guarantee |

1. Inspect `list_training_instruments`, `describe_training_instrument`,
   `get_training_instrument_provenance`, `list_training_assets`, and `list_classic_algorithms`.
   Use bounded FIT metadata queries where useful. Determine whether the advertised target
   and feature representation can address the question you selected.
2. Create a deterministic FIT exposure with explicit `seed`, `epoch`, `episode_count`, and
   allowed `origin_spacing_minutes`. Retain the returned exposure identifier and provenance.
   The fallback SplitMix64 sampler is deterministic, but historical research bitwise parity
   is `UNVERIFIED`; do not describe that parity as validated.
3. Materialize the exposure with one advertised `target_index` and
   `CLASSIC_LAST_AND_MEAN_V0`. The managed view retains its hashes and exclusions. Large
   tensors are not returned for arbitrary client-side execution.
4. Choose an advertised CPU algorithm and bounded hyperparameters for the question. Supported
   classic regressors are Ridge, ElasticNet, Random Forest, and HistGradientBoosting. Ridge
   and ElasticNet use a FIT-fitted StandardScaler; tree models do not. Preserve the training
   seed, specification, model ID, and provenance.
5. When the work is ready, request `evaluate_classic_model_on_monitor(model_id=...)`. This
   evaluates server-side and returns aggregate metrics, not MONITOR rows. Interpret those
   metrics in light of the question, selection history, bounded FIT exposure, and limitations.
6. Report what was attempted, immutable artifact references, the finding, and what remains
   uncertain. An inconclusive or adverse result is reportable. These outputs are not a backtest,
   proof of alpha, a profitability result, or a trading instruction.

This sequence describes tool dependencies, not a prescribed experiment. The scientific workflow does not accept general workspace uploads. It does not expose
custom feature code, arbitrary asset-subset training, shell execution or unrestricted model fitting. Repository-local Dataset,
Feature, Experiment, and Historical Study labs are separate facilities, not additional public
MCP capabilities. Do not infer access to them from the product name.

## Protected evidence and errors

MONITOR is not training data. Never request its exposure, labels, target-valid arrays, feature
matrices, or per-row predictions/targets. Repeated evaluation of the same model is blocked.
Different experiments do not make prior MONITOR exposure disappear: disclose prior evaluation
when interpreting later findings. Sentinel and sealed future data remain unavailable at every tier.

The World Model and Opportunity Discovery instruments are provenance-only in V0 and fail closed
for inference. Cached World States are not model inference; corpus Opportunity targets are not
model predictions. Generic `.pt`, pickle, filesystem-path, GCS-URI, code, training/fine-tuning,
optimizer, and GPU operations are not available.

Treat MCP `isError` results as failures even when HTTP succeeds. `AGENT_AUTH_REQUIRED` means
authenticate; `DATA_ACCESS_LIMIT_EXCEEDED` means inspect and respect the bounded scope;
entitlement or concurrency denials mean inspect your current allowance and outstanding work.
Do not retry policy denials unchanged or work around them with another identity. A private
runtime failure is not a scientific finding; retain the error category and report the limitation
without claiming a completed artifact. Unexpected errors must not be filled in with invented results.

## Paid Compute Pricing

```text
PRICING: PUBLISHED
BILLING: NOT_YET_ENABLED
PAID_EXECUTION: NOT_YET_ENABLED

Credit purchase: US$10 = 100 ASNOMIC credits
Minimum purchase: US$10
Standard CPU compute: approximately 3–4 credits per active compute hour
L4-class GPU compute: approximately 15–18 credits per active compute hour
Storage: small additional usage-based credit charge
```

Paid compute pricing is published for evaluation and planning.
Purchasing credits and executing paid workloads are not yet enabled during the current Private Beta.

These are provider-independent ASNOMIC product prices, not pass-through infrastructure prices.
Free `ASNOMIC_USAGE_UNIT_V0` entitlement units are an onboarding/access-control mechanism.
Paid ASNOMIC credits are the planned commercial compute currency. No conversion between free
units and paid credits is defined. Your free allowance is not a paid-credit balance or a promise
of CPU time. Billing, payment processing, checkout, purchased-credit balances, paid-credit ledger,
paid workloads, and wallet payments are not implemented.