Viska-Autoresearch — Operator Decisions Log

Recorded live during phase-3 decision walkthrough (2026-05-25).

Source reports: - REPORT.md (phase 1) — D1–D8 - REPORT-PHASE2.md (phase 2) — D9–D13

Resolution Summary (2026-05-25)

Tally: 8 decided, 5 deferred. None blocking stage-1 architecture lock.

Companion principles surfaced: - "Keep costs low for implementation phase, only scale ops and costs once proven" (D8) - "We can afford to take the time to ship this properly" (D12) - "Strict isolation and security restrictions on this agent" (D11)

New phase-3 tasks introduced by decisions: - T24 — Metis LLM-wiki design (from D12) - T25 — Synthesis pipeline spec (from D12) - T26 — Hermes ↔ staging access boundary (from D12) - T27 — Mastra read path (from D12) - T28 — Self-hosted bge feasibility on Railway (from D2) - T29 — Railway IMDS exposure probe (from D7) - T30 — Stage-1 telemetry schema (from D4)

Pending handoffs: - Operator → Viska legal: D1 GDPR/EU residency question - Operator → Anthropic console/sales: D3 ZDR contract verification - Hermes → Metis: D6 wiki tier schema review, D12 LLM-wiki architecture handoff - Hermes → Proteus: D6 viska-research RLS + role provisioning review

D9 · Adopt hermes-agent

Answer: ADOPT (operator, 2026-05-25)

Adoption under 5 mandatory guardrails per REPORT-PHASE2.md §"5 guardrails": 1. Pin to v2026.5.16 (v0.14.0) 2. OS-level sandbox (D10 selects which) 3. Pantheon-authored skills only (D11) 4. Mirror fork 5. Accept 4–8 week hook half-life

Gates D10, D11, D12, D13 active.

D3 · Anthropic ZDR active on Pantheon account?

Answer: DEFERRED — out of scope for this arc (operator, 2026-05-25)

Flagged for later. Treat as "unknown" until confirmed. Working assumption pre-resolution: route Plutus review LLM through OpenRouter ZDR-filtered provider, not direct Anthropic. Revisit before stage-1 go-live.

D11 · Skill install trust ceiling

Answer: PANTHEON-AUTHORED ONLY (operator, 2026-05-25)

Operator directive: "strict isolation and security restrictions on this agent." Maps to most-restrictive option.

Enforcement: - Block agentskills.io network reach at Envoy egress allowlist (T6 item). - CI signature gate at Hades layer — only Pantheon-signed skills install. - No community skills, no Nous-bundled skills outside Pantheon-reviewed subset. - Re-author the ~10 hardening skills (T6 plugin list) under Pantheon namespace. - Any Nous-bundled skill we want must be forked into Pantheon-mirror first, reviewed, signed, then loaded.

D10 · Sandbox posture

Answer: HARDENED DOCKER COMPOSE (stage 1) (operator, 2026-05-25)

Ship-fastest path. Use Nous-shipped Compose config + Hades tightening pass (~1–2 days). Defer NVIDIA OpenShell to stage 2 (post stage-1 stable + Railway-feasibility spike).

Stage-1 hardening checklist (Hades-owned): - read_only: true rootfs - cap_drop: [ALL], selective cap_add - Non-root UID - tmpfs for /tmp, no host bind mounts - Network namespace isolated from other Railway services - Resource limits (memory, pids, cpu) - No /var/run/docker.sock exposure

Tension with D11 strictness flagged: D11 = max-restrictive skill ceiling, D10 = baseline sandbox. Acceptable stage 1 because skill ceiling already collapses the dominant code-injection vector. Stage-2 OpenShell tightens the residual.

D13 · Upgrade cadence

Answer: REVIEW-GATED ROLLING with buffer + revert (operator, 2026-05-25)

Not a fixed clock cadence. Each upstream release reviewed; merge only after Pantheon plugin re-test passes. Buffer + revert path mandatory.

Process requirements: - Mirror fork (guardrail #4) is the merge surface. No direct upstream auto-pull. - Buffer period: new upstream tag soaks N days (TBD, suggest 7d) before review starts. Skips week-of churn. - Plugin re-test gate: all 10 Pantheon hardening plugins must pass on candidate tag before merge to production fork branch. - Easy revert: keep last-known-good tag pinned in Railway config. Revert = single env-var bump + redeploy. No DB migrations coupled to Hermes upgrades (enforce at schema-design layer). - Audit trail: every upgrade reviewed against upstream changelog + commit diff. Hades captures changelog summary + risk flag per release.

Effective velocity expected: ~monthly under normal conditions, accelerated for security-flagged releases, paused indefinitely if upstream breaks plugin contract.

Operator gate: each merge requires explicit operator sign-off (no auto-merge from review pass alone).

D12 · Memory provider

Answer: TWO-TIER — Holographic for Hermes working memory + new Metis-owned LLM wiki for client research data (operator, 2026-05-25)

Architectural decision beyond pure provider pick. Splits state into two distinct surfaces:

Tier 1 — Hermes agent working memory

• Provider: Holographic (local SQLite, free, trust scoring built-in).
• Scope: transient turn-state, intermediate reasoning, /goal Ralph loop continuity, ephemeral context.
• Durability: acceptable if lost on redeploy — Hermes can rehydrate from staging artifacts.
• Mount: Railway volume for SQLite file so redeploys preserve when needed.
• Isolation: stays inside Hermes container. No external egress for memory ops.

Tier 2 — Client research LLM wiki (NEW component)

• Owner: Metis agent (constellation-metis).
• Substrate: sophisticated LLM-wiki model (Aion-pattern: pgvector + graph relations + semantic search + retrieval-grade synthesis).
• Hermes access: none OR partial-staging-only. Hermes does NOT read the synthesized wiki directly.
• Synthesis pipeline: Hermes raw outputs land in staging → Metis-driven synthesis cron promotes to wiki with deduplication, conflict resolution, source attribution, embedding.
• Metis access: full read/write.
• Mastra access (client-facing): read via Metis-mediated API or direct read of synthesized layer (TBD in T16 follow-up).
• Plutus access: full read for review/gating decisions.

Implications + follow-ups

• Schema split (revises T2 / D6): viska-research Supabase gains explicit boundary — staging.* (Hermes-writable) vs wiki.* (Metis-only-writable). RLS enforces.
• New component: Metis synthesis service. Scoping work needed — new phase-3 task.
• Timeline accepted: operator explicit "we can afford to take the time to ship this properly" — Tier 2 is not stage-1 blocker. Stage 1 ships with Tier 1 + staging-only writes; Tier 2 + synthesis lands stage 1.5 or stage 2.
• Security win: Hermes never holds full client knowledge graph in working memory. Compromise of Hermes container ≠ exfil of full wiki.
• D11 alignment: matches strict-isolation directive — Hermes minimum-knowledge, Metis full-knowledge, asymmetric trust.

New follow-up research tasks (add to phase-3 candidate list)

• T24 · Metis LLM-wiki design — substrate choice (Aion vs custom), schema, synthesis algorithm, dedup + conflict policy, embedding strategy, retrieval interface.
• T25 · Synthesis pipeline spec — Hermes-staging → Metis-wiki promotion mechanics. Trigger (cron / event), batching, validation gate, error handling, idempotency.
• T26 · Hermes-↔-staging access boundary — exact write API + RLS, what Hermes can read back from its own staging (for self-continuity vs forced amnesia).
• T27 · Mastra read path — does Mastra read wiki via Metis API or direct Supabase? Affects auth model + Slack response latency.

D1 · EU data residency required for Viska?

Answer: DEFERRED TO VISKA LEGAL — working assumption NO (operator, 2026-05-25)

Route question to Viska legal counsel before stage-1 go-live. Working assumption pre-resolution: not required → OpenRouter US routing acceptable, Supabase US region acceptable.

Pre-resolution stance: - Stage-1 architecture proceeds on US-routing assumption. - PII tokenization plugin (T6/T12) becomes more important — if tokenization strips identifiers before LLM call, GDPR Article 44 transfer concern likely moot regardless of legal answer. - Reversal path: if legal returns "yes, EU required" → OpenRouter Enterprise EU + Supabase region migration. Schema-design rule: avoid hard region coupling stage 1 so migration is feasible.

Open follow-up: handoff to operator → Viska legal pings. Hermes session cannot escalate directly.

D2 · Embedding model

Answer: VOYAGE-3-LITE primary, SELF-HOSTED bge exploration, OPENAI-3-small fallback (operator, 2026-05-25)

Three-tier embedding strategy. Scope: Metis LLM wiki (Tier 2 from D12). Hermes Tier 1 memory unaffected.

Primary: Voyage-3-lite

• Dim 1024. Finance-tuned. $0.02/M tokens.
• Locked column dim across wiki.* tables → 1024.
• Default for stage-1 ship.

Exploration: self-hosted bge-large-en-v1.5

• Dim 1024 (matches Voyage — no schema change needed for swap).
• Avenue to evaluate post stage-1 stable.
• Drivers: data sovereignty, D11 strict-isolation alignment, future EU-residency reversal of D1.
• Cost: Railway service (Python + ~1.3GB weights). Ops surface trade-off accepted as exploration cost.
• Scope: new phase-3 candidate task (see below).

Fallback: OpenAI text-embedding-3-small

• Dim 1536 → schema mismatch with primary. Cannot drop-in swap on existing wiki.* tables. Fallback requires either:
• Separate wiki_openai.* mirror tables at 1536-dim (parallel maintain), or
• Full re-embed migration on swap (expensive).
• Use case: Voyage outage / quota exhaustion / pricing shift. Accept re-embed cost as DR-grade event.

Implementation notes

• Wiki schema design column-dim parameterized via env var, not hardcoded literal — eases self-hosted swap path.
• Embedding provider abstracted behind Metis-internal interface (single-method embed(text) -> vec).
• Audit log per embedding call (provider, model, dim, timestamp) — supports later corpus re-embed planning.

New follow-up research task

• T28 · Self-hosted bge feasibility on Railway — model load time, inference latency, memory footprint, batch throughput, GPU vs CPU performance, cost vs Voyage at projected volume.

D5 · Plutus review cron cadence

Answer: DEFERRED — blocked on T14 (Hermes↔Plutus communication layer design) (operator, 2026-05-25)

Operator correction: Plutus runs as Claude Code session on subscription, NOT API. Phase-2 cost framing ($1650–8200/mo) was wrong premise — per-wake LLM cost effectively bundled in CC subscription quota.

True cost shape (revised): - CC subscription quota consumption (Pantheon plan) - Machine resource occupation (which physical/virtual machine hosts the Plutus session) - Schedule slot availability (CC session concurrency limits per machine) - NOT per-wake dollar cost

Why deferred

Communication layer Hermes ↔ Plutus has not been engineered. Cadence decision depends on delivery mechanism. Open questions blocking D5:

1. Wake mechanism — how does Hermes notify Plutus that an artifact awaits review? Tmux send-keys, file-drop trigger, Mastra-mediated, Slack DM, war-room cron skill?
2. Response channel — how does Plutus signal approval/rejection back to Hermes? Same channel reverse, Supabase status-column UPDATE, Slack ack?
3. Session lifecycle — Plutus always-fresh per wake, or stateful across wakes? Persistent tmux pane vs spawn-per-task?
4. Machine assignment — which machine hosts Plutus sessions? Machine-awareness rule applies. Currently unknown.
5. CC subscription concurrency — can one Pantheon subscription sustain market-hours 2-min cadence across all war-rooms? Quota math unknown.
6. Multi-tenancy — Plutus is shared across war-rooms (multiple Viska + non-Viska clients?). Sharing model TBD.
7. Failure mode — what if Plutus session unreachable (subscription quota hit, machine offline, CC crash)? Hermes queues + retries, or halts pipeline?
8. Latency floor — Claude Code session boot + context-load takes seconds to ~minute. 2-min cadence may be physically infeasible per-session.

Action

T14 scope expanded to cover communication-layer design. D5 revisits after T14 lands.

Working assumption pre-resolution: event-driven only (Hermes signals Plutus on artifact-ready, no clock cron) — physically simplest, defers all open questions, lowest CC quota consumption. Trading-grade latency surrendered stage 1; research-grade acceptable per D12 operator note ("we can afford to take time to ship this properly").

D6 · Status-column vs status-namespace on research.signals

Answer: STATUS COLUMN BOTH SURFACES + STRICT RLS — pending Metis + Proteus review (operator, 2026-05-25)

Working decision: status-column pattern on both Hermes staging tier and Metis wiki tier. RLS enforces lifecycle transitions + tier boundaries.

Subject to schema-design review by Metis (wiki tier owner per D12) and Proteus (viska-research Supabase owner per phase-1 T2).

Lifecycle states (working spec)

Hermes staging tier (staging.*): - draft — Hermes writing in progress, not ready - ready_for_synthesis — Hermes signals artifact complete, awaits Metis pickup - synthesized — Metis has consumed, row may be archived/pruned per retention policy - rejected — Plutus or Metis rejected during synthesis review - archived — terminal, soft-delete

Metis wiki tier (wiki.*): - active — current canonical fact/entity - superseded — replaced by newer row (versioning chain via supersedes_id) - archived — soft-delete, retain for audit

RLS requirements (strict)

• Hermes role: INSERT + SELECT + UPDATE-own-rows on staging.* only. Zero access to wiki.*. State transitions limited to draft → ready_for_synthesis.
• Metis role: SELECT + UPDATE on staging.* (for synthesis pickup + state advance), full CRUD on wiki.*. Cannot demote wiki.active → staging.*.
• Plutus role: SELECT on both tiers (review needs visibility). UPDATE-status only — ready_for_synthesis → rejected, wiki.active → wiki.superseded. No INSERT/DELETE.
• Mastra (client read path): SELECT on wiki rows where status='active'. Zero access to staging.*. TBD via T27.
• Force RLS on every table (ALTER TABLE ... FORCE ROW LEVEL SECURITY) — RLS applies even to table owner.

Review handoff

Filing return-handoffs to: - Metis — wiki tier schema review, retention policy for superseded, versioning chain semantics. - Proteus — viska-research SSOT impact, RLS policy authoring, role provisioning, existing schema integration.

Both reviews complete before T13 (schema migration) executes.

D7 · Container runtime / IMDS exposure on Railway

Answer: DEFERRED — T29 probe task added (operator, 2026-05-25)

Definitive answer requires empirical test inside Railway container, not just docs lookup.

New follow-up research task

• T29 · Railway IMDS exposure probe — deploy minimal probe container. Attempt curl --max-time 2 against:
• http://169.254.169.254/latest/meta-data/ (AWS IMDS)
• http://169.254.169.254/computeMetadata/v1/ (GCP-style)
• http://metadata.railway.internal/
• http://metadata.google.internal/
• RFC1918 ranges (172.16/12, 10/8) for unexpected internal services
• Report: HTTP codes, response bodies, latencies. Zero secret access — structure-only probe.
• Cross-check against Railway Trust Center docs.
• Time: ~30 min including Railway deploy.

Working assumption pre-resolution

Envoy egress sidecar (T11) DENIES 169.254.0.0/16, metadata.*, and all RFC1918 ranges by default. Belt-and-suspenders regardless of T29 outcome.

Threat-model line stays: TM-5 (credential exfil) + TM-7 (IMDS abuse) closed at egress layer even if Railway platform exposes IMDS.

D8 · Nous rate-limit tier

Answer: DEFAULT TIER (180 RPM) stage 1 — scale only after proven (operator, 2026-05-25)

Operator principle: "keep costs low for implementation phase, only scale ops and costs once proven."

Stage-1 stance

• Nous Portal Default tier (180 RPM, 3 req/sec sustained).
• Estimated cost: $23–55/mo light volume per phase-2 T1.
• No Ultra-tier commitment until telemetry justifies.

Cutover criteria (Default → Ultra)

Reassess Ultra tier ONLY when telemetry shows: - Sustained 429-throttling from Nous Portal across multiple consecutive days, OR - Karpathy loop completion latency degrades past acceptable threshold due to RPM cap, OR - Multi-agent fan-out pattern (parallel Hermes subagents) creates burst exceeding 180 RPM.

Implementation requirement

• Per-call rate-limit telemetry plugin (Hermes pre_api_request hook) — capture every Nous request: timestamp, RPM-window position, response code, latency.
• Daily aggregate logged for trend visibility.
• Throttle-event alerts if 429s seen.

Companion principle (operator-stated)

"Keep costs low for implementation phase, only scale ops and costs once proven" applies fleet-wide to viska-autoresearch decisions. Bias all open tuning choices toward minimum-viable cost stage 1, scale on telemetry evidence stage 2+.

D4 · Stage-2 trigger criteria for broker creds

Answer: DEFERRED — broad instrumentation during stage 1, decide at stage-1→2 transition (operator, 2026-05-25)

Decision deferred to real-data point rather than picked now from prior. Commits to broad telemetry during stage 1 so any reasonable gate can be evaluated post-hoc.

Stage-1 instrumentation requirements

All of the following captured from day 1 to support stage-2 gate decision later:

Plutus agreement signal: - Every Plutus approval/rejection logged with: artifact ID, decision, confidence, reasoning summary, timestamp. - Operator override events captured separately: artifact ID, original Plutus call, operator final call, delta classification (false-approval / false-rejection / agreement). - Rolling N-day agreement rate computed (N parameterized — 7d, 14d, 30d windows).

Strategy quality signal (requires T18 — backtesting infra): - Every synthesized strategy backtested against historical data. - Capture: Sharpe, max-drawdown, win-rate, sample size, backtest period. - Walk-forward validation if infra supports.

Signal quality signal: - For research signals (pre-strategy): forward-looking accuracy when ground-truth resolves. - Time-to-resolution per signal type.

Pipeline health signal: - Hermes uptime, error rates, plugin failures. - Plutus session availability (D5 communication-layer reliability). - Wiki sync lag (Hermes staging → Metis wiki promotion latency).

Failure-mode catalog: - Every Plutus rejection categorized (operator-driven taxonomy: hallucination, stale data, calc error, etc.) — informs which failure classes block stage 2.

Stage-1→2 decision process

At stage-1 stable mark (TBD weeks post go-live), operator + Hephaistos + Plutus session jointly review telemetry. Stage-2 gate criteria emerge from data, not predetermined.

Companion follow-up tasks

• T18 (existing) — backtesting infra. Becomes load-bearing for stage-2 evaluation.
• T30 (new) · Stage-1 telemetry schema — define exact tables/columns for the five instrumentation surfaces above. Touches viska-research Supabase + needs Metis/Proteus review.

Trade-off accepted

Cost: broad instrumentation adds engineering during stage 1 build. Schema bloat. Storage growth. Benefit: decision-grade telemetry available when stage-2 question lands. No regret over premature criteria lock-in.