Viska sjóðir · Weekly Meeting · 2026-05-20
A tour of the two war rooms
The architecture and topology behind your trading and research stack.
Apollo · Plutus · Mímir-Mastra
02
Viska-AI · two war rooms
Opening frame
We're building Viska two parallel systems, not one. They share infrastructure but do different jobs, on different schedules, with different people in the room.
Think of them as two specialized teams that meet at a common dinner table — one team builds the kitchen, the other team cooks every day.
We call them war rooms.
The system at a glance
War room 1 of 2
Designs, builds, tests, and deploys the stack — the infrastructure the live trading system runs on. Moves on a developer's schedule: features, deploys, fixes, releases.
It does not trade. It does not touch markets.
What lives here
War room 2 of 2
Runs the live, day-to-day analytical and trading work using the stack the backend team builds. Moves on a market schedule: pre-market, open, intraday, end-of-session.
What lives here
Why two rooms instead of one
Risk guarded against
The active room cannot accidentally deploy a half-built feature into a live market session.
Independence preserved
The backend room cannot freeze the active room while testing an unrelated change.
Each room runs on its own clock, with its own people, against its own goals — while sharing the same underlying memory and data.
How work gets tracked
What this means for Viska
Every piece of work you'll ever ask us about has a permanent, dated, linkable record. No chat history. No memory dependence.
You'll eventually get a read-only view into the boards relevant to Viska.
Backend room — the build crew
| Group | Agent | What they do |
|---|---|---|
| Orchestration brain | Mímir-Mastra | Reasons about the live system state, answers operator questions in Slack — eventually answers your questions in Slack. The persona you'll talk to. |
| Workflow plumber | Mímir-n8n | Owns the visual workflow tool that publishes summaries, watches for files, posts to Slack. Connective tissue between system and you. |
| Design + delivery | Apollo | Owns client-facing surfaces — dashboards, slide decks, reports, the visual layer. Handles Icelandic localization. |
| Coordinator | Plutus | Runs the room. Tracks what's in flight, dispatches work, files cross-team handoffs, owns the GitHub pushes for the room. |
Active room — the trading floor
| Group | Agent | Equivalent at a traditional fund |
|---|---|---|
| Research analyst | trading-analyst | Reads market data and macro indicators, produces the daily research note. Your buy-side desk analyst. |
| Risk officer | trading-risk | Watches position size, concentration, drawdown limits. Vetoes trades that breach the mandate. Your risk function. |
| Execution desk | trading-execution | Translates approved signals into orders against the paper Alpaca account. Files database records. Your trading desk. |
| Operator / supervisor | trading-operator | Reads the analyst's note, decides what's approved, signs off the end-of-day summary. PM + ops lead. |
| Coordinator | Plutus | Same Plutus identity as the backend room — runs the active room session, files the day's artifacts, owns audit attribution. |
Outside both rooms
Hades
Credential vault
Owns API keys, tokens, anything secret. No keys ever pass through agent chat.
Proteus
DB + infrastructure governance
Owns the trading SQLite database, Supabase tables, server provisioning.
Atlas
Fleet operational rules
Owns the playbook every agent reads at session start.
Hermes
Research scout
Pulls in external intelligence (papers, repos, vendor analysis) on request.
Memory layer · surface A
Mímir answers questions about a body of pre-loaded research — papers, articles, fund documents, market literature that the operator has explicitly ingested.
You ask in Slack. Mímir reads the corpus. Mímir answers.
This is what you've been seeing for several months.
Memory layer · surface B · new
Every time any agent produces a piece of research — daily note, risk assessment, synthesis, override reasoning — it gets harvested into a structured knowledge graph.
The graph captures
For Viska leadership
You'll browse this knowledge graph directly — a kind of internal Wikipedia automatically maintained by the system rather than written by hand.
Why this matters for Viska specifically
Funds accumulate institutional knowledge that lives in PM heads, email threads, Slack DMs, abandoned docs.
The LLM Wiki gives Viska a persistent, searchable, attributable memory of every analytical decision the system makes, queryable in plain language.
Auditors, future hires, and Viska leadership see the same picture six months later as the trading-operator saw the day the decision was made.
What we feed the system
Market data · live
Market data · historical
Macroeconomic context
News + sentiment
Internal research
Alpaca paper is the v1.0 substrate. Live capital is a v2.0 decision — requires Viska sign-off on mandate, risk gating, audit layer.
How we intend to use the data
Analyst and risk officer pull from market data + macro + news to produce the daily note and gate decisions on live signals.
The knowledge graph lets Mímir answer comparative questions ("how does this week's setup compare to three weeks ago"), surfacing patterns no single human catches across that span.
The SQLite log + knowledge graph together mean every trade decision, every research output, every override can be reconstructed years from now. Your fund-level audit trail.
Section 6 · what's next
27
Tracked items
From paper trading → a real, tenant-isolated Viska dashboard: live IBKR positions, live Iceland cash, weekly allocation history, AI-driven analysis.
Group A — International brokers + data ingestion
IBKR Flex web service
Account U22131377 · Viska Macro Fund
Daily institutional pull — positions, cash by currency, fills. Backfill to inception (Oct 2025).
Iceland Open Banking · AIS
Íslandsbanki · Audkenning eID
Direct OAuth, ~90-day token. Replaces hardcoded ISK 80M kr with a live balance, refreshed daily.
FX rates
Daily ISK→USD
From Seðlabanki XML or ECB. Anchored to broker-day snapshot.
+ 3 supporting items
Pull schedule · normalization · audit log
Cadence config, currency-pair normalization, and dated SQLite audit rows for every pull.
Owners: hades (credentials) · pantheon-ops (ingestion) · plutus (Open Banking client)
Group B — Backend gates
We do not show Viska a live URL until all five gates close.
G1
Close 27 anon-readable financial tables · RLS posture
G2
Schema isolation · dash_core + dash_gulli_macro
G3
Auth provisioning · dashboard_users + JWT-claim RLS
G4
IBKR Flex wired into n8n
G5
Cloudflare DNS + cert for the dashboard host
Owner: proteus · plus pantheon-ops on G4
Group C — Dashboard frontend
App shell · fork
Gulli's 548-line viska-dashboard.jsx
March 27 IBKR snapshot → production app shell.
D1 · PortfolioDashboard
YFIRLIT · ÞEMU · STÖÐUR · AI GREINING
Four tabs, wired to live IBKR + ISK feeds.
D2 · AllocationHistoryDashboard
Weekly aggregation cron
Oct 2025 backfill + ongoing weekly snapshots.
D3 · CompanyProfilesDashboard
Seeded from prototype's 24 entries
Plus admin-edit form for editorial profile updates.
Mastra runtime
Replace browser→Anthropic call
Existing prototype path is broken + key-exposure risk. Proper server-side runtime needed.
+ 2 bug fixes
Prototype bugs · pre-deploy
Two known issues on the existing 548-line file must close before any deploy.
Owners: apollo (frontend) · proteus (ticker coverage)
Group D — Decisions to close
Each is a decision the operator + Viska need to make jointly. Staged on the board so nothing is forgotten.
D-01
Editorial profile ownership
Who writes the Icelandic ticker descriptions — Gulli, Hermes, hybrid?
D-02
Screener tool — v1 or v2?
Ship in launch or defer to Phase 2.
D-03
Theme-at-time tracking
Does allocation history reflect historical theme tags?
D-04
Browser-scrape data sources
Adopt for "impressive" wow factor or stay API-only?
D-05
Anthropic key invoicing
Shared or per-tenant billing?
D-06
Subdomain pattern
Path-based vs subdomain-based tenant routing.
Group E — Phase 2
P2-01
Screener tool
If punted from v1.
P2-02
Multi-tenant onboarding
Supabase Phase 2 tier — capacity for additional client tenants beyond Viska.
P2-03
Iceland banking via PSD2
If any manual fallback is needed during v1.
Total scope
27 items · A·6 + B·5 + C·7 + D·6 + E·3
Owners across the board
hades · proteus · apollo · plutus · pantheon-ops · hermes
Reading the board
Each item carries
agent:hades, agent:proteus, …)Board
github.com/orgs/boas-dev/projects/2Nothing is improvised. Everything traces to a written plan you have access to.
Closing frame · 30 sec
The system is not magic and not a black box. Every piece is named. Every piece has an owner. Every piece writes a record.
Questions you ask today should be answerable by Mímir tomorrow — citing the agent, the date, and the source.