# Extending the framework (extension points) portfolio-optimiser is a generic core with explicit **config seams** (D4/D5, 90 %-prinsippet): you onboard a new project, a new data source, or a new model-map **without editing the core `src/portfolio_optimiser/*.py`**. The three guides below name the exact seam for each. > **Honesty note (rent teknisk rammeverk).** The bundled reference domain > (`data/reference_projects.json` + `data/docs//`) is a set of **SYNTHETIC, AI-authored > fixtures** — fictional construction-cost projects, dummy estimates, and placeholder > `verdict_input` decisions. They are flagged in each file's `_note`. A production deployer > **replaces the data source** with their own and supplies **Layer-2 verdicts via real HITL** > (fageksperter), not static config. The static `verdict_input` field is a test-fixture > convenience that stands in for the durable HITL verdict in the offline synthetic framework. ## Legg til eget prosjekt A new project is **config + docs only** — no code change (this is exercised by the SC1 test `test_e_new_project_flows_through_via_config_only` + the `test_f_no_hardcoded_project_ids_in_src` guard, which fails if any project id leaks into `src/`). 1. Append an entry to `src/portfolio_optimiser/data/reference_projects.json` with the full key set: `id`, `name`, `description`, `currency`, `cost_items`, **`docs_dir`**, and **`verdict_input`** (`{"decision", "rationale"}`). - `docs_dir` is a path **relative to the package `data/` root** (e.g. `"docs/MY-PROJECT"`); the loader (`reference_domain.load_reference_projects`) resolves it to an absolute path. - `verdict_input` carries the (synthetic) Layer-2 decision/rationale; flag it in the file's `_note` as synthetic if it is not a real expert verdict. 2. Create the bundled docs folder `src/portfolio_optimiser/data/docs//` with at least one text file whose content names the cost-saving measure/terms (so `retrieve_chunks` returns at least one citable chunk). 3. Run the project: `run_portfolio(["MY-PROJECT"], "local", client_factory=...)` (or include it in the default fan-out by passing no `project_ids`). ## Legg til egen datakilde The retriever (`retrieval.py` / `datasource.py`) reads a **local docs folder** per project, selected by the project's `docs_dir` in `reference_projects.json`. To point a project at your own data, change its `docs_dir` to your folder and drop your cost documentation there — the citation seam (`{file, locator, snippet, score}`) is identical on the in-process tool and MCP paths. The folder is boundary-checked (fail-closed) against path traversal, so keep documents inside the configured `docs_dir`. A real deployer swaps the bundled synthetic docs for their own source. ## Legg til egen modell-map Model choice is **config, not code** (B12): `src/portfolio_optimiser/data/model_map.json` maps `profile -> role -> model/deployment` (`resolve_model(profile, role)`). To use your own models: - Edit the `local` block to your local model ids (Ollama/LM Studio), and/or - Edit the `azure` block to your Foundry deployment names (the placeholders `REPLACE-WITH-FOUNDRY-DEPLOYMENT` are tenant-specific — replace them or supply via env). The role keys (`proposer`, `checker`, `default`) let you assign a distinct model per debate role; `default` is the fallback when a role is unmapped. ## Legg til en ingest-kilde (http-familien som worked example) The **ingest layer** (`ingest.py`, spec `shared/ingest-spec.md`) is a second, distinct source seam from the retriever above: one JSON **manifest** per source coupling declares a `source.type` and a list of extractions; `materialize(...)` runs the connector for that type and writes an OKF bundle. > **Where to change it (2026-07-20):** `ingest.py` is a thin adapter — Door A is implemented by > the shared [`llm-ingestion-okf`](https://git.fromaitochitta.com/open/llm-ingestion-okf) library > (git-pinned to `v0.3.1`), so connectors, materialization and index generation improve in ONE > place across every consumer. `shared/ingest-spec.md` remains the normative spec — the library > implements it, it does not replace it, and spec changes go via commons. The API below is > unchanged; only the implementation moved. Note that Door A is **ungated**: it calls no > security guard before writing to disk, so gating untrusted content is the caller's > responsibility (see `docs/plan/2026-07-16-llm-ingestion-guard-inclusion.md`). The spec ships three source families — `file`/CSV (I2), `sql` (I4), and **`http`** (I6) — and `http` is the framework's **worked extension-point example**: it shows exactly how a third, network-transport family plugs into the same connector / materialization / gate contracts. The `http` manifest contract (spec §4): - `source.base_url` — the endpoint root; it **must not embed credentials** (userinfo is rejected at schema validation). - `source.credential_ref` — the **name of an environment variable** holding the secret, resolved at run time (sent as `Authorization: Bearer `); the secret is never read from the manifest, never logged, never stamped in the generated frontmatter. `null` → no auth. - each extraction's `query` is joined onto `base_url` and its response body is rendered **verbatim inside a fenced code block** (not a markdown table — a raw `|` or `\` survives un-escaped); `max_rows` caps the response line count, fail-fast (never silent truncation). **Network is a per-run grant, never a manifest field (spec §8).** `materialize` refuses an `http` source unless the caller passes `allow_network=True`: ```python # refused fail-fast — the manifest cannot grant itself network access: materialize(manifest, bundle_dir, ingested_at="2026-07-04T12:00:00Z") # opted in explicitly by the operator for this run: materialize(manifest, bundle_dir, ingested_at="2026-07-04T12:00:00Z", allow_network=True) ``` This is the **local-only default, no silent egress** principle made mechanical: configuration is data that cannot escalate its own authority; only the runtime `allow_network` grant can. The transport itself is an **injectable seam** — `materialize(..., http_get=)` swaps the GET implementation (the default `_urllib_get` is the only socket path). The golden case (`examples/ingest-golden-http/`) and every test inject a canned `get` over committed fixture payloads, so the suite runs offline against a **local mock** — no live source, no credentials. **The default transport is time-bounded (S2.4).** The library's `_urllib_get` calls the stdlib opener without a timeout, which falls back to the process-wide default socket timeout — `None` out of the box — so a source that accepts a connection and then never answers would hang a run, contradicting the invariant that nothing runs unbounded. `materialize` therefore hands the library that same socket path wrapped in `ingest.timeout_get`, which scopes `socket.setdefaulttimeout` (`HTTP_TIMEOUT_SECONDS`, 30s) around the delegate call: the bound applies **without** a second socket path and **without** duplicating the credential header, so the pinned library stays untouched. An explicitly injected `http_get` is passed through **unwrapped** — a caller-supplied transport owns its own timeout policy. **Honest limit:** the default socket timeout is *process-global*. Under `concurrency=k` the runner is asyncio on a single thread, so the scoping holds. Driving `read_http` from a thread-pool executor would make it unsafe, and the bound would have to move to a per-call timeout argument — i.e. to owning a socket path locally. ### D7 sibling hook — MCP as an extension of this family The spec (§4) documents an **MCP-based connector as an extension of the `http` family**, not a new client wired into the optimiser run path — that stays a **Non-Goal** here: the in-process `FunctionTool` seam is the default in the run path, and MCP is demonstrated (via `build_mcp_server` in `datasource.py`), not wired in. **The connector (S2.2, 2026-08-02).** `ingest_mcp.py` implements it. There is **no fourth source family and no schema change**: an MCP source is an ordinary `type: "http"` source whose transport is declared by the `base_url` scheme, and whose two parts fall straight out of the join the library already performs (`base_url` + `/` + `query`): ```json { "type": "http", "id": "docs", "base_url": "mcp+stdio://PORTFOLIO_DOCS_MCP" } ``` ```python from portfolio_optimiser.ingest import materialize from portfolio_optimiser.ingest_mcp import mcp_get, stdio_call_tool materialize(manifest, bundle_dir, ingested_at="2026-08-02T00:00:00Z", allow_network=True, http_get=mcp_get(stdio_call_tool())) ``` `server_ref` is the **name of an environment variable** holding the server command — mirroring the `sql` family's `connection_ref`, so the manifest carries a reference and never an executable path — and the extraction's `query` is the tool name. Parsing is string-based, not `urlsplit`-based: `urlsplit().hostname` lowercases the host, which would silently break a case-sensitive env lookup. Two properties are worth stating because they are **inherited, not written**: the §8 network grant covers MCP for free (an MCP source *is* `http`, so it is refused before any tool call unless `allow_network=True`), as do the `max_rows` cap, verbatim fenced rendering, and the §7 provenance stamp. Had MCP become a fourth family, each of those would have been ours to write — and ours to forget. The transport discriminator **gates rather than labels**: `mcp_get` refuses a URL it does not own, so an MCP transport can never quietly serve a plain `https://` manifest and leave the bundle's provenance claiming a transport that was never used. **Verified against a real MCP server subprocess (2026-08-03).** `stdio_call_tool` was previously written but never executed end to end; `examples/ingest-golden-mcp/` + `tests/test_ingest_golden_mcp.py` now run it against a live server process — byte-identical golden extraction, plus the tool-error and missing-`server_ref` branches. Five detach mutations measured RED (unwrap, `initialize()`, error-code identity, the `isError` branch, one body byte). A local subprocess costs no model tokens, so the cost discipline is untouched; the contract tests still inject a canned tool and spawn nothing. **What running it actually found — the error contract was broken.** `stdio_client` and `ClientSession` are each an anyio task group, and anyio re-packages anything leaving one in a `BaseExceptionGroup`. Every error raised inside the session (`mcp_tool_error`, `mcp_non_text_content`) therefore reached callers as an exception group, never as the `IngestError` the whole Door A path catches and switches on by `code`. Fixed by unwrapping the group and re-raising the owned error; anything unowned is re-raised untouched. **No canned-tool test could have caught this** — they never enter a task group. This is the case for running what you ship. **A server on this path must expose a null-argument tool.** The URL carries both coordinates and the tool is called with an empty argument dict, so `datasource.build_mcp_server` **cannot** serve ingest: its `retrieve_cost_docs(query)` has a required parameter (verified — it returns an error result). The two are separate seams by design: `build_mcp_server` serves the agents' retrieval path. **Still true:** MCP remains **unwired in the optimiser run path** — the in-process `FunctionTool` seam stays the default there. The timeout path (`asyncio.wait_for`) is not covered by a test. **Where the D7 sibling stands (målbilde §11 boundary).** The Claude Agent SDK sibling built the **file/CSV and SQL** connectors — mirroring I3/I5 — with bit-identical golden extractions. **HTTP and MCP are implemented on the MAF side only**; the sibling ships no network connector and no live-source integration. `ingest_mcp.py` is deliberately MAF-free (it imports the open `mcp` protocol client, never `agent_framework`), so the seam is portable to D7 unchanged. On D7 the in-process server hook is `create_sdk_mcp_server(name, version="1.0.0", tools=...) -> McpSdkServerConfig` (package `claude-agent-sdk`) — verified 2026-07-04 against the official Claude Agent SDK Python docs — but that is a **documented hook a deployer would reach for, not a shipped D7 connector**; no D7 MCP session is planned. Nothing here contacts a live endpoint. ## Bytt ut henteren (Embedder / Retriever, S3.1) How prior verdicts are ranked is a seam, not a hard-coded sort. `semretrieval.py` declares two protocols and the store delegates to them: - **`Retriever`** — `rank(query, candidates, k) -> list[Verdict]`. `VerdictStore.retriever` defaults to `None`, which means `StructuralRetriever`: the same weighted structural score and `(-similarity, id)` ordering the store used before the seam existed. Assign your own object with a `rank` method to replace ranking wholesale. - **`Embedder`** — `__call__(features) -> np.ndarray`. `HybridRanker(embedder, similarity, weight)` blends `weight * cosine + (1 - weight) * structural`; both terms live in `[0, 1]`, so `weight` means what it reads as (`SEMANTIC_WEIGHT_DEFAULT = 0.25`). **Your vectors must be finite.** `cosine` raises `ValueError` on a NaN or infinite norm rather than scoring it — a non-finite score compares `False` against everything, which leaves the ranking in whatever order the input happened to arrive in and defeats the total order `HybridRanker` otherwise guarantees. A zero vector is fine and scores `0.0`; the asymmetry is deliberate, because zero is a state the shipped `FakeEmbedder` produces on purpose whereas non-finite only ever means the embedder is broken. Coercing it to `0.0` would hide that as "no semantic similarity" and let ranking proceed on a forged signal. ```python store.retriever = HybridRanker(MyEmbedder(), similarity, weight=0.3) ``` Note that `similarity` is **injected**, not imported by `semretrieval`. That is deliberate: `verdicts.py` imports `agent_framework`, and injecting the score keeps the retrieval layer free of it (guarded by `tests/test_semretrieval_loadbearing.py`, which ranks in a subprocess and then asserts `verdicts` never entered `sys.modules`). Keep that property if you extend the module. **A real embeddings client is a code-level extension point — it is not built here.** Selection goes through a CLOSED registry: `--embedder-config` names a type, `build_embedder` dispatches on it, and an unknown type is refused rather than resolved. A dotted `module:Class` import path is deliberately *not* supported — that would be arbitrary code execution at config-load time and would hand a config file the ability to import something that opens a socket, routing around the no-network guard (which is scoped to `semretrieval.py` and blind to a third module by construction). Adding a real embedder therefore means adding a registry branch in code, plus any capability opt-in as a factory kwarg — the same discipline `NotifierConfig` applies to egress. The shipped `FakeEmbedder` is a deterministic sha256 projection with no semantics; it exists so the seam is exercisable offline at zero cost, and the load-bearing proof is that removing the cosine term flips the ranking, not that the projection is meaningful. A deployer supplying a real client owns its network egress, cost, and the fact that it embeds proposal **text** — which is why the hybrid is opt-in (`--semantic-retrieval`) rather than the default. If you wire one in, note that `semretrieval` currently imports no network module at all, and a guard test asserts exactly that; a real client belongs behind the `Embedder` protocol in *your* module, not inside this one. **Optional persistence — an unwired authoring primitive.** `save_vector_store(dir, verdicts, embedder)` / `load_vector_store(dir)` write and read a byte-deterministic `vectors.npy` + `vectors.jsonl` pair (sorted by verdict id, atomic replace). A missing store loads as `None`; a row/line mismatch raises rather than silently mis-ranking. `*.npy` is gitignored. They have **no caller in `src/`**, and ranking never reads a persisted matrix: `HybridRanker.rank` re-invokes the embedder for every candidate on every call, so a persisted store would be bypassed even if one existed. They are offered to extenders, on the same footing as `write_verdict`, `promote_verdict` and `build_mcp_server` — public primitives the core deliberately does not wire into `run_project`. Wiring the cache in only becomes worth anything once the ranker is changed to consult it, which is a redesign rather than a hookup. *Known limitation:* the empty-store branch hardcodes `EMBED_DIM`, so a third-party `Embedder` of a different dimension writes a shape-inconsistent empty store. Stated, not fixed. ## Bevisst ikke bygget (90 %-kuttlista) Per the design philosophy (a ~90 % generic core with clear extension points — we do not chase the last 10 %), the following are **deliberate cuts**, not roadmap debt. Each is extension territory for a deployer, with the seam named: - **B10 — full verdict-conflict taxonomy.** Chosen minimal semantics (documented in `verdicts.py` + README): the in-memory store is first-write-wins per verdict id; the disk layers (`write_verdict`, `promote_verdict`) are last-write-wins per file. The full taxonomy (rejection categories + a rule for conflicting expert verdicts) is deferred until real experts produce conflicting verdicts. - **B11 — expert notification.** `run_project(notify=...)` remains a plain-callable seam (`run.py` auto-wires no default notifier), but the core now ships the declared `Notifier` contract (`notify.py`, exported from the package top) with three implementations: `ConsoleNotifier`, `FileNotifier` (byte-deterministic JSONL), and `WebhookNotifier` — plus a fail-fast `build_notifier(config, *, allow_egress=...)` factory. The webhook is the ONLY egress point and is fail-closed behind an explicit per-run `allow_egress=True` opt-in (a code kwarg, never a config field — mirroring the ingest layer's `allow_network`). SSRF guards, HMAC signing, and auth headers remain deployer-owned extension points on the injectable `WebhookPost` transport seam. Webhook URLs must start with `http://` or `https://` — a scheme-less URL is rejected fail-fast at config construction. - **U12 — checkpointing / crash-survival of a run.** A run either completes or is re-run; the async verdict inbox (step 7) is the resumable boundary, not intra-run state. - **U14 — OpenTelemetry / observability.** Provenance stamping is the audit trail the core ships; OTEL wiring is a deployer concern. - **Concurrent fan-out.** `run_portfolio` iterates projects sequentially by design (fresh per-project execution state; one threaded `VerdictStore`); parallel orchestration is left to the deployer and would need budget-cap coordination.