Dewey is the canonical artifact registry and artifact-resolution service for the stack. It gives analysis and delivery systems a stable place to register artifact identity, sets, share references, and links to external objects without handing artifact authority to the portal or the lab system.
Dewey owns:
- artifact identity and artifact metadata
- artifact-set identity and membership
- artifact resolution and storage metadata lookup
- share-reference issuance
- external object links to artifacts and artifact sets
Dewey does not own:
- customer release visibility decisions
- Atlas storage policy authority
- wet-lab or analysis execution state
flowchart LR
Clients["Atlas / Ursa / operators"] --> Dewey["Dewey API + small browser UI"]
Dewey --> TapDB["TapDB persistence"]
Dewey --> Cognito["Cognito / daycog"]
- Python 3.11+
- local PostgreSQL/TapDB-compatible runtime
- HTTPS certificates for the normal local path
- optional Cognito setup for the browser UI
source ./activate <deploy-name>
dewey config init
dewey db build --target local
dewey server start --port 8914source ./activate <deploy-name> creates the deployment-scoped conda environment from repo-root environment.yaml when it is missing, then activates it and installs only the Dewey repo editable.
HTTPS is the expected local posture. Dewey now resolves TLS material in this order:
- explicit
--certand--key - generic
SSL_CERT_FILEandSSL_KEY_FILE - legacy
DEWEY_SSL_CERT_FILEandDEWEY_SSL_KEY_FILE - shared deployment-scoped Dayhoff certs under
~/.local/state/dayhoff/<deploy-name>/certs/ - repo-local
certs/cert.pemandcerts/key.pemas a temporary compatibility fallback - mkcert generation into the shared deployment-scoped Dayhoff cert directory
Use --no-ssl only when you explicitly want an HTTP local run.
- FastAPI + Jinja2
- Typer-based
deweyCLI - TapDB-backed persistence
- Cognito-backed browser auth
Dewey centers on:
- artifacts
- artifact sets
- external objects and external-object relations
- share references
- resolution requests that map identifiers to storage metadata
- app factory:
dewey_service.app:create_app - CLI:
dewey - main CLI groups:
server,db,config,env,test,quality
Current major route groups include:
- artifact registration and lookup under
/api/v1/artifacts - artifact-set registration and membership under
/api/v1/artifact-sets - resolution flows under
/api/v1/resolve/* - share references and external-object relations under
/api/v1/*
The browser UI is intentionally narrow and focused on search, anomalies, observability, and literature-oriented workflows.
Approximate only.
- Local development: workstation plus local database.
- Shared sandbox: generally a modest portion of the broader Dayhoff-managed service footprint.
- Production-like environments cost more because registry availability, storage metadata, TLS, and database uptime matter more than the Dewey code itself.
- Canonical local entry path:
source ./activate <deploy-name> - Use
dewey ...for Dewey-owned operations - Use
tapdb ...for shared DB/runtime lifecycle when Dewey explicitly delegates it - Use
daycog ...for shared Cognito lifecycle when Dewey explicitly delegates it dewey db reset --target localdeletes the current local TapDB target and rebuilds itdewey db nuke --target localdeletes the current local TapDB target without rebuilding
Useful checks:
source ./activate <deploy-name>
dewey --help
pytest -q- Safe: docs work, tests,
dewey --help, and local-only runtime checks - Local-stateful:
dewey db build --target local - Requires extra care: HTTPS cert management, Cognito lifecycle, and any deployed environment integration