Crypto Intelligence Terminal — OpenAI Build Week

An isolated Evidence Review Assistant extends an existing crypto paper-trading and market-intelligence terminal with structured, evidence-cited post-trade reviews. The Build Week extension combines deterministic rules with an optional OpenAI Responses API provider while remaining unable to place, modify, or close trades.

Safety boundary: this repository is for paper trading, education, and software evaluation. Review output is not financial advice. The Build Week assistant has no execution controls.

Project overview

The baseline repository contains the Crypto Intelligence Terminal: a FastAPI-based paper-trading terminal with market monitoring, a browser dashboard, deterministic intelligence modules, session controls, trade journaling, and optional Telegram notifications.

The OpenAI Build Week work adds build_week_extension/evidence_review_assistant, a standalone review pipeline that:

• accepts a strict, bounded evidence contract;
• validates and normalizes synthetic trade evidence;
• produces deterministic observations and rule-based inferences;
• selects either a deterministic mock provider or an OpenAI provider;
• requests schema-constrained output through the OpenAI Responses API;
• validates citations and maps results into one stable review schema; and
• fails safely without affecting the terminal or any trade state.

The default provider remains MOCK. The extension is not wired into the baseline production runtime.

Problem statement

Post-trade analysis is often fragmented across lifecycle data, market context, execution quality, and indicator snapshots. Explanations can blur recorded facts, deterministic inference, and AI interpretation, making them difficult to audit.

The project addresses three questions:

1. What was directly observed?
2. What follows from explicit, reproducible rules?
3. What interpretation did the selected provider add, and which evidence supports it?

Solution approach

The assistant uses a layered review process:

1. Schema validation rejects unknown or incorrectly typed input.
2. Semantic validation rejects impossible timestamps, prices, ranges, or lifecycle relationships.
3. Normalization creates deterministic canonical evidence without inventing missing fields.
4. Rule evaluation separates observations, supporting evidence, opposing evidence, execution quality, and gaps.
5. Provider selection chooses MOCK or OPENAI through explicit configuration.
6. Structured validation constrains OpenAI output with Pydantic and rejects unknown evidence citations.
7. Output assembly returns one EvidenceReviewOutput with explicit provenance and uncertainty.

See ARCHITECTURE.md for the full design.

Architecture overview

Synthetic evidence
      │
      ▼
Pydantic contract ──► semantic validator ──► deterministic normalizer
                                                │
                                                ▼
                                         local rule engine
                                                │
                         ┌──────────────────────┴──────────────────────┐
                         ▼                                             ▼
                 MockReviewProvider                            OpenAIProvider
                 deterministic output              lazy Responses API + validation
                         └──────────────────────┬──────────────────────┘
                                                ▼
                                     EvidenceReviewOutput

Provider implementations share the structural BaseReviewProvider interface. The service does not contain provider-specific request logic.

Technology stack

• Python 3.11
• FastAPI and Starlette
• Pydantic 2
• OpenAI Python SDK and Responses API
• pytest
• HTTPX
• Baseline terminal: SQLAlchemy, aiosqlite, APScheduler, WebSockets, HTML/CSS/JavaScript
• Git SHA-256 manifests and controlled provenance reports

Safety boundaries

• The Build Week extension imports no module whose name begins with backend.
• Current evidence normalization accepts approved synthetic evidence only.
• Neither provider exposes trade execution, exchange, database, Telegram, or filesystem mutation tools.
• The OpenAI request contains only bounded normalized evidence and deterministic review summaries.
• The request sets store=False.
• Provider output must match a Pydantic schema and cite known evidence IDs.
• API keys, prompts, evidence, and response bodies are never logged.
• Provider failures become bounded PROVIDER_ERROR review results.
• The mock provider performs no network activity and remains the default.

Repository structure

crypto-intelligence-build-week/
├── backend/                    # Existing terminal and intelligence implementation
├── frontend/                   # Existing dashboard assets
├── config/                     # Existing application configuration source
├── build_week_extension/
│   └── evidence_review_assistant/
│       ├── api.py              # Standalone FastAPI routes
│       ├── models.py           # Input and output contracts
│       ├── evidence_normalizer.py
│       ├── review_rules.py
│       ├── provider_config.py  # MOCK / OPENAI selection
│       ├── mock_provider.py
│       ├── openai_provider.py
│       ├── prompt_builder.py
│       └── samples/            # Six fictional fixtures
├── tests/build_week/           # Isolated Build Week verification suite
├── docs/build_week/            # Phase documentation
├── research/                   # Copy/provenance research artifacts
├── review/                     # Integrity and transition reports
├── ARCHITECTURE.md
└── DEMO_GUIDE.md

Local setup

Windows PowerShell:

cd "D:\path\to\crypto-intelligence-build-week"

C:\Path\To\Python311\python.exe -m venv .venv
.\.venv\Scripts\python.exe -m pip install fastapi==0.115.0 pydantic==2.9.2 pytest==8.3.2 httpx==0.27.2 "uvicorn[standard]" openai

.venv/ is excluded from Git. Do not commit credentials or environment contents.

Configuration

Provider selection is explicit and defaults to mock:

from build_week_extension.evidence_review_assistant.provider_config import (
    ProviderKind,
    ReviewProviderConfig,
)
from build_week_extension.evidence_review_assistant.service import EvidenceReviewService

service = EvidenceReviewService(
    config=ReviewProviderConfig(provider=ProviderKind.MOCK)
)

To select OpenAI, use ProviderKind.OPENAI. The provider reads configuration only when instantiated or executed:

Variable	Required	Purpose
OPENAI_API_KEY	For an actual OpenAI review	Read only when the lazy SDK client is first created.
OPENAI_MODEL	No	Overrides the single internal model default.
OPENAI_TIMEOUT	No	Positive request timeout in seconds; default is 30.

Never place real values in tracked files, fixtures, commands committed to Git, or screenshots.

Running the demo

The safest demonstration uses the deterministic mock provider and a bundled fictional fixture:

@'
from build_week_extension.evidence_review_assistant.sample_repository import SampleRepository
from build_week_extension.evidence_review_assistant.service import EvidenceReviewService

sample = SampleRepository().load("profitable_trend_trade")
result = EvidenceReviewService().review(sample)
print(result.model_dump_json(indent=2))
'@ | .\.venv\Scripts\python.exe -

To expose the standalone mock API locally:

.\.venv\Scripts\python.exe -m uvicorn build_week_extension.evidence_review_assistant.api:app

Then open http://127.0.0.1:8000/docs or request:

Invoke-RestMethod http://127.0.0.1:8000/build-week/evidence-review/samples/profitable_trend_trade

See DEMO_GUIDE.md for the 2–3 minute walkthrough.

Testing

$env:PYTHONDONTWRITEBYTECODE = "1"
.\.venv\Scripts\python.exe -m pytest tests\build_week -q -p no:cacheprovider

The suite covers normalization, deterministic rules, schema failures, provider selection, lazy client creation, mocked Responses API success/failure, citation validation, safe logging, timeout configuration, network denial, backend-import isolation, and historical fingerprint integrity.

Limitations

• The Build Week assistant is standalone and not connected to the terminal dashboard.
• Current evidence input is restricted to approved synthetic fixtures.
• Automated OpenAI tests use injected fake SDK clients; they do not prove account access or model availability.
• The default FastAPI application uses the mock provider.
• Reviews are explanatory and non-causal; incomplete evidence reduces confidence.
• No review persistence, authentication layer, deployment configuration, or submission hosting is included.
• The legacy repository-wide suite contains five deployment-package checks whose source artifacts were intentionally excluded from the controlled Build Week copy; the isolated Build Week suite is the submission verification target.
• Repository publication, licensing, deployment, and Devpost submission require separate approval.

Future roadmap

The following items are future work, not implemented features:

• reviewer-facing dashboard integration;
• opt-in review persistence and comparison views;
• evaluation datasets beyond the six synthetic scenarios;
• authentication, rate governance, and deployment hardening;
• human feedback and quality-scoring workflows; and
• separately approved production integration that preserves the no-execution boundary.

Documentation

• Architecture
• Demo guide
• Build Week changelog
• P3A implementation notes
• P4A baseline transition