// Help / how-to page — comprehensive documentation of the dashboard for the // portfolio manager. Static content; no DB payload required. // // Structure: // - TL;DR // - Quick guide (5 steps) // - The six pages — one section each, with an expandable "deep dive" // describing how the underlying methodology was constructed // - Data foundation (universe, refresh cadence, "as of" semantics) // - Glossary const _SECTION_MAX_WIDTH = 880; function HelpHeader() { return (
01 · /Q.INTRO

Intro.

portfolio-manager guide · methodology deep-dives
); } function HelpKicker({ label }) { return ( {label} ); } function HelpSectionTitle({ children }) { return (

{children}

); } function HelpProse({ children }) { return (
{children}
); } function HelpCallout({ children }) { return (
{children}
); } // Native
with styled marker — clicking the summary expands the // deep-dive content inline. No React state needed. function DeepDive({ label, children }) { return (
▸ Deep dive · {label}
{children}
); } function HelpKeyValue({ k, v }) { return (
{k} {v}
); } // Reusable: one "page" entry with title, one-paragraph description, and a // deep-dive collapsible underneath. function PageEntry({ num, title, oneLiner, useFor, deepDiveLabel, deepDive }) { return (
{String(num).padStart(2, '0')}

{title}

{oneLiner}

USE {useFor}

{deepDive}
); } function PageHelp() { return (
{/* ─── TL;DR ──────────────────────────────────────────────────────────── */}
What is this?

Cortex is a research prioritization tool for Nordic small-caps. Every night it pulls fresh prices and reports for every instrument on Nordic First North and Small Cap lists, recomputes a 6-factor scorecard (quality, value, growth, momentum, inflection, risk) for ~750 eligible names, bins them into five signal buckets, and ranks within each bucket by a research-priority composite.

You don’t use it to pick stocks directly — you use it to decide which 5–15 names to spend research time on this week. Everything below the queue (tear sheet, similarity, models, backtest) is decision support, not signal generation.

Updated nightly at ~03:00 UTC. The header shows the precise built_at timestamp of the data you’re looking at.

{/* ─── Quick guide ────────────────────────────────────────────────────── */}
A 90-second weekly workflow
  1. Open Research Queue. Scan the top of each bucket. Compounders are the long-term core; cheap_decent are deep-value plays; inflection candidates are turnarounds with early momentum; pullbacks are quality names that just sold off; danger is your “don’t touch” list.
  2. Filter to your appetite. Use the bucket / country / sector chips and the min-quality / max-risk sliders. A typical PM scan: buckets = compounder + cheap_decent + inflection, min-quality = 60, max-risk = 60.
  3. Click any row → Drill In. The drill-in panel shows the factor breakdown and the AI text signal (recent press releases scored for operating momentum, balance-sheet risk, dilution risk, etc.). If it’s interesting, hit “Open tear sheet”.
  4. Use Tear Sheet → Similar To…{' '} to broaden the set. If you like the company but want comparables, Similar To finds the 12–15 closest names by financial fingerprint across the whole Nordic universe (not just the queue).
  5. Watchlist & Notes{' '} to track decisions. Hold / Watch / Pass with a one-line rationale. Notes are timestamped so you have a paper trail of why you skipped a name three months ago.
{/* ─── The six pages ──────────────────────────────────────────────────── */}
What each page does, and how it’s built

Six factor scores (quality / value / growth / momentum / inflection / risk) are computed for each eligible company. Each factor is a weighted blend of cross-sectionally rank-z-scored sub-features. Buckets are then assigned by eligibility cuts on those factor scores:

Within a bucket, the rank comes from a composite that’s bucket-specific. Compounder, for example, weights quality 0.45, growth 0.225, momentum 0.135, value 0.09, AI-text 0.10, with a −0.25 risk penalty. Each composite is normalized over the factors actually present for that company — so a name with no recent AI-scored docs still gets a valid composite.

A company can satisfy multiple buckets’ cuts. In practice it goes into the “best” one by composite score; ties are broken in the order compounder → cheap_decent → inflection → pullback → danger.

} />

Each of the six factor scores is a 0–100 cross-sectional rank. The underlying sub-features and weights:

Ranks are computed within the eligible universe at the feature_date, so a 70 today and a 70 a year ago aren’t directly comparable — they always describe position relative to today’s Nordic small-cap pool.

} />

Each eligible company at the feature_date is represented by a 12-dim vector covering five aspects:

  • Operating profile: gross margin, EBIT margin, FCF margin, ROIC
  • Growth: revenue CAGR 3y, EBIT growth YoY
  • Balance: net debt / EBITDA, equity ratio
  • Size + liquidity: log market cap, log 90-day avg daily turnover
  • Capital discipline: 3y share-count growth

Each dimension is normalized via percentile-rank → z-score (robust to small-cap outliers vs raw values), then pairwise Euclidean distance is computed. NaN-tolerant: missing features in a pair are masked out and the distance is scaled by √(D / n_present), so a sparser pair doesn’t artificially look closer.

Top-K neighbours per company are persisted to cortex.similar_companies nightly. There’s also a semantic similarity path via OpenAI text-embedding-3-large on a per-company summary doc (annual report + 90-day press releases), kept in cortex.company_embeddings{' '} — currently not exposed on this page, but available for future “narrative similarity” views.

} />

For each historical feature_date, the queue methodology is re-applied to the universe as it was on that date, top-N names per bucket are “held” for 12 months, and the portfolio’s forward return is compared against the equal-weighted benchmark over the same instruments.

Transaction cost + slippage budget is configurable (defaults to 40 bps round-trip, applied at each rebalance). Portfolio sizing is bucketed: min 10 / max 50 names per portfolio, top-percent threshold defaulting to 10% of the eligible pool.

Walk-forward avoids look-ahead bias. The score-construction weights, eligibility cuts, and bucket composites are the same in-sample and out-of-sample — there’s no fitting on the test windows.

} />

Three production models, trained on the same monthly feature panel (~200 features per company-month, 36-month lookback):

All models are evaluated by walk-forward: train on data up to t−12m, predict at t, score on the realized 12m return through t+12m. The hit-rate and excess-return-12m columns are aggregated over all out-of-sample folds.

Features are monthly-aggregated (e.g. month-end revenue, returns, margins), so model predictions are stable within a month and refresh meaningfully at month-end. The nightly job does not re-run inference for this reason — model predictions are refreshed in a separate monthly schedule.

} />

Two underlying tables: cortex.watchlist (the current status per security_id with a one-line rationale) and cortex.notes (append-only log; each note has author, date, body).

The queue join applies the watchlist state as the heldand watch booleans per row, which the queue’s row chips render directly. There’s no separate state stored on the row — the queue is always re-derived from watchlist + scores at build time.

Decisions ( cortex.decisions ) is a third table that exists for future use — to log explicit buy/sell decisions with size and price. Not wired into the UI yet.

} />
{/* ─── Data foundation ────────────────────────────────────────────────── */}
Universe, refresh, and freshness

The universe is every instrument on Nordic First North + Small Cap lists across Sweden, Norway, Denmark, Finland, and Iceland that Börsdata exposes. That’s ~1700 instruments raw, narrowed to ~750 with enough fundamental history to compute the full feature stack. Currently-listed First North 25 constituents are flagged with a chip in the queue.

The header timestamp (data as of …) is the precise moment the nightly job wrote the on-screen payloads to the database. The asof date ( asof 2026-04-01) is the feature_date the queue is computed at — typically the most recent quarter-end with closed reporting.

If “data as of” is more than ~36 hours stale, the nightly refresh hasn’t completed successfully. Check the GitHub Actions logs of the nightly-refresh workflow in garage-projects-ab/scai.

The 03:00 UTC workflow in order:

Model rankings (LightGBM / transformer) are NOT in nightly — they’re refreshed in a separate monthly workflow because the features feeding them are monthly-aggregated.

{/* ─── Glossary ───────────────────────────────────────────────────────── */}
Terms & symbols
); } window.PageHelp = PageHelp;