# Platform overview

Klineo brings public market observations, issuer planning, deterministic studies, human review, liquidity operations, and verification into one evidence workflow. Treasury teams can inspect conditions, compare a proposed change with a baseline, record a decision, and trace an eligible transaction through finality and reconciliation.

The issuer's Safe controls custody and onchain authorization. Klineo provides calculation, review, transaction preparation, monitoring, and evidence records. A developer credential or completed analysis does not grant the issuer's signing authority.

## Start with the right context

There are three distinct contexts in the product. Read the page's context label before interpreting its metrics or controls.

| Context | What it provides | How to interpret the result |
| --- | --- | --- |
| Design demo | Synthetic projects, charts, studies, and workflow examples | Use it to learn the interface. Its values, signatures, approvals, and outcomes are illustrative. |
| Testnet sandbox | Test-only assets and bounded testnet mechanics | It can demonstrate contract interactions in its stated test environment. It does not establish issuer-Safe ownership or production acceptance. |
| Connected workspace | Records returned by the configured API for the selected organization | Inspect source coverage, versions, freshness, and release status. Connected data alone does not mean execution is enabled. |

The current canonical release configuration targets BOT testnet `968`, with live activation and automated execution disabled. BOT mainnet `677` is supported by shared types but remains gated. External EVM market observations can be read-only even when the issuer's execution context is BOT. Check the application's `/status` page for the connected deployment's execution and funding state.

## How the pieces relate

An **organization** is the private workspace and access boundary. Its members have roles, and its credentials have explicit scopes. Selecting another organization changes the private records you can read or modify.

An **issuer** is the team responsible for a token's liquidity policy and capital. A public token identifier, saved project bookmark, or project-control record has a specific verification scope; none should be treated as an issuer-Safe approval.

A **project** groups saved public observations and analysis context. A **market** is the chain, asset pair, and venue or pool being observed. A **vault** is the separately qualified issuer-owned liquidity system, with its own strategy, policy, inventory, and execution evidence.

A **study** calculates a modeled outcome from captured inputs and assumptions. A **Decision Pack** preserves a private human analysis record. A **proposal** describes a specific candidate change for separate review and approval. These records serve different purposes and do not automatically advance one another.

## The end-to-end workflow

### 1. Inspect a public project

Open `/app/analyze` to inspect a supported public identifier. The public observation service currently covers supported Base/Virtuals identifiers and their supported canonical pool evidence. It reads public information without requiring a vault or an ownership claim.

Inspect the chain, resolved token, pool, block identity, reserves, token precision, and gaps. Pool existence and an offchain project mapping do not prove token ownership, transferable liquidity, executable quotes, transfer-tax behavior, or a complete project-health assessment.

An authenticated member can deliberately save the observation in `/app/projects`. Saving creates workspace history; refreshing creates a new observation generation. Earlier analyses continue to reference the observations they captured.

### 2. Establish the issuer workspace

Invited users authenticate and select an organization. Owners manage membership, while analysts, treasury administrators, approvers, and viewers receive different permissions. The API checks authorization independently of which controls appear in the interface.

Issuer onboarding at `/app/onboarding` verifies the Safe and qualifies the assets, pool, venue, strategy, and policy context before a vault can advance. A public project bookmark can support analysis without this custody workflow.

### 3. Observe markets and treasury context

Use `/app/markets`, `/app/treasury`, `/app/today`, and `/app/data-health` to inspect available market, inventory, treasury, and source-health evidence. The treasury workflow can preserve declared assumptions and historical scenarios; a projection does not establish current spendable cash.

Use each view's units and source cutoff. A value in quote atomic units is not automatically a fiat amount, and a market chain is not automatically the vault's execution chain.

### 4. Plan and run a study

Use `/app/plan`, `/app/research`, or `/app/simulate` to define the question, select exact source generations, review assumptions, and compare a baseline with alternatives. Manual studies and guarded Research tasks retain their respective inputs and evidence.

A study is reproducible within its engine version and declared model. It is a hypothetical calculation. Failed trials, unavailable inputs, unverified units, and model limits remain relevant when evaluating a result. A saved task receipt confirms admission; inspect the task and report state to determine whether work completed.

### 5. Record a human decision

Use `/app/decision-packs` to preserve a question, supporting evidence, assumption notes, rationale, and follow-up. Supported packs can reference partial public evidence, Research candidates, or a historical treasury scenario under their own contracts.

The pack lifecycle includes draft, ready for review, decision recorded, follow-up due, closed, and superseded states. “Ready for review” means its supported evidence can be reviewed. A recorded decision does not approve a financial proposal, publish a report, or schedule an external notification.

### 6. Review an eligible financial proposal

Use `/app/strategies` to define strategy and policy candidates, then `/app/proposals` for the v2 proposal workspace. The existing Safe review workflow remains available at `/app/decisions`.

A financial proposal binds the exact candidate, source evidence, policy, simulation, limits, and expiry required by its workflow. Reviewers inspect the changes and record their approvals according to organization roles. Internal approval is separate from the Safe's threshold signature and onchain result.

### 7. Prepare, authorize, and reconcile

When the required policy, source, deployment, approval, and release checks pass, the product can prepare an exact reviewable Safe transaction packet. The issuer signs and submits through its own Safe workflow. Current canonical release gates keep live automation disabled.

Registering a transaction begins verification. Inclusion, finality, and reconciliation are separate stages. Klineo checks the recorded transaction against the expected action and resulting inventory or positions. A submitted transaction is not a successful outcome; mismatches and failed executions remain visible.

### 8. Monitor and publish evidence

Use `/app/vaults`, `/app/intelligence`, and `/app/incidents` to review positions, quality, attribution, alerts, and response records. Source degradation or a pause changes what the system can safely admit.

Use `/app/reports` for finalized outcomes and saved analysis reports, observing their distinct report types. An issuer-selected disclosure and publication workflow determines what becomes public. Published outcomes resolve at `/proof/:slug`; signed Liquidity Passports resolve at `/passport/:slug`. The public reader receives the permitted verification material, not access to the private organization.

## Where developers fit

The TypeScript and Python SDKs use the versioned HTTP contract. They support organization-bound access to permitted studies, scores, proposals, receipts, proof, alerts, and other scoped resources. Service credentials expose a narrower surface than interactive workspace sessions.

Use the least scope needed for your integration, retain the returned record versions and evidence identities, and treat unavailable or conflicted responses as unresolved conditions. SDK methods do not hold Safe keys, sign issuer transactions, or create arbitrary execution authority.

Continue with [Architecture](/platform/architecture) for component responsibilities and [Data lineage](/platform/data-lineage) for interpreting evidence and versions.