Polarize
GitHub Get in touch

Changelog

What changed in the code.

Merged pull requests across the public polarizetech repositories, newest first, synced from GitHub once a day. Every repository, with the posts about it, is under Work.

2026-10-18 polarize-ui #5

Add reusable 3D node-link network view

Summary

  • add a dependency-free mountNetwork3D renderer with orbit, zoom, depth sorting, token colours, and accessible keyboard controls
  • ship public TypeScript declarations and integration documentation
  • add a synthetic Storybook example and API/design checks

Verification

  • python3 dev_check.py: 507/507 passed
  • TypeScript: passed
  • API surface removal check against v0.6.0: passed

This is an additive public API. It contains only a standard node-link visualization and synthetic story data; Neural Field Lab’s model remains in world-seeding.

2026-10-18 scientific-research-agents #1

Add sensory experts and standardize agent workflows

Summary

  • add first-priority expert profiles for auditory evoked potentials, visual evoked potentials, and bone-conduction hearing
  • define positive and negative routing boundaries, ordered pathway tracing, stimulus-design requirements, and dissociation controls
  • require every lead and specialist agent to use the Scientific Research RAG MCP backed by polarizetech/retrieval-augmented-generation before any search
  • permit only service-unavailable and explicit user opt-out exceptions, requiring disclosure before fallback
  • standardize visual design on the configured design system; Polarize installations use pinned releases of polarizetech/polarize-ui
  • require missing reusable UI elements to be added, tested, released, and pinned from the design-system repository rather than forked locally
  • standardize small apps as zero-build index.html / app.js / app.css plus a Python serve.py
  • prefer stdlib ThreadingHTTPServer, named-file asset allow-lists, PORT support, loopback binding, explicit /api/ contracts, and Python ownership for non-trivial backends
  • document React/framework exceptions and frontend/computational-engineer ownership boundaries
  • add focused routing, inherited-policy, and shared-app-architecture contract tests
  • bump the synchronized release metadata to 0.5.0

Validation

  • python3 -m unittest discover -v tests — 13 tests passed
  • git diff --check — clean
  • architecture checked against the scaffold protocol and representative apps:
    • audio-evoked-potentials/apps/tuning-forks
    • matched-entropy-demodulation/apps/v15-visual-cortex
    • world-seeding/apps/primary-elements/v1
  • primary-literature web cross-checks completed for the initial sensory profile seeds
  • Polarize RAG/RREG and its citation checker were unavailable during initial profile creation; the scientific profiles mark unverified material accordingly

Limitations

  • Scientific limitations and read-depth caveats remain embedded in each sensory profile.
  • The RAG citation checker validates quotations and numbers, not entailment.
  • The Python stdlib server is a default for small research apps, not a ban on React, FastAPI, Flask, static-only hosting, or an established repository stack; deviations must name the requirement.
  • Repository-local files remain authoritative for their own current contents.
  • Private or user-supplied material is not indexed into a shared corpus without authorization.

Cross-repository pointer

The reciprocal AEP README pointer is committed separately in polarizetech/audio-evoked-potentials as 2981f09, because one Git branch cannot span two repositories.

2026-10-15 polarize-ui #4

feat!: remove the cell field; the homepage story is the shipped page

Removes the animated cell field (<ui-cellfield>, CellField, ./cellfield.js, .ui-cellfield*) at the operator’s request, and rebuilds the Landing homepage story as the page polarize.tech now ships (fieldguide). Adds an optional media prop to ProjectFeature.

Breaking. api_surface.py --removed v0.5.19 lists exactly the cell field’s surface. No consumer uses it: polarize.tech dropped it in v0.5.19; joshuaanderton.ca and the monorepo never used it.

Checks: dev_check 491/491, build_css/build_shadcn –check, tsc; Storybook homepage story renders with no errors.

🤖 Generated with Claude Code

2026-10-15 polarize-ui #3

feat: fieldguide theme — white, magenta, Geist

Opt-in fieldguide theme (white page, magenta accent, Geist sans) and additive landing components for polarize.tech’s restyle: .ui-action, .ui-stats, .ui-steps--rows, .ui-topics, .ui-specimen-tile, .ui-plate--ink, and the crab/neuron/magnet specimens.

Non-breaking: existing themes render unchanged (cards read --landing-radius/--landing-fill with the old values as fallbacks); api_surface.py --removed v0.5.18 is empty. dev_check 497/497, build_css/build_shadcn –check, tsc pass.

🤖 Generated with Claude Code

2026-10-13 retrieval-augmented-generation #9

Document how to add a paid patent service for the pipeline alone

Documentation only; no code changes.

patent-fetch asks its paid providers (SerpApi) only when they are named. The patents companion’s config entry already passes an env to the command it starts, so naming the provider set there adds one for the pipeline alone:

"env": {"PATENT_FETCH_SEARCH_PROVIDERS": "europepmc,epo-ops,lens,serpapi"}

A search from patent-fetch’s own command line still asks its usual set.

  • config/mcp-gateway.example.json: an empty env on the patents companion and an _env_comment saying what it is for, what it needs, and what it costs (one paid search per planner query, up to seven more when a query matches nothing and is retried).
  • docs/research-pipeline.md: a paragraph on the same, with what a live check on 2026-10-13 returned. The patents paragraph above it is rewrapped; it had lines over 100 columns and its text is unchanged.

Checked: the example config still parses and the companion still loads from it; 252 tests pass.

🤖 Generated with Claude Code

2026-10-13 retrieval-augmented-generation #8

Patents companion: short queries, a fallback for empty ones, room for recent patents

The “Existing patents on this” section of a run on 2026-10-13 showed only patents from 1996 to 2001, although the patent services hold ones from 2024 and 2025 on the same subject.

Cause. A patent service returns only records with every word of a query in the title or abstract. The planner had been asked for queries “naming the invention and what it does the way a patent title would”, and wrote a six-word one that matched nothing at either service; the other matched only patents using an older term.

Changes, all in research_pipeline/companions.py:

  • The planner is asked for 1-3 queries of 2 to 4 words each, and told that every extra word finds fewer patents (max_queries 2 → 3).
  • A query of 3 to 7 words that matches nothing is asked again with one word left out at a time. The answer’s limits name the query, say why it matched nothing, and say how many records asking again found.
  • Of the six entries listed, four are the closest titles and two are the most recent of the rest, so old patents whose titles repeat the question cannot fill every place. The section’s first line says this.

Checked against the live services with the two queries from that run: the six-word query now recovers 10 records through the fallback, and the section lists patents from 2025, 2024, 2016 and 2014 beside those from 1999 and 2011. Tests: 252 pass; ruff, pyright clean.

Not checked: a full pipeline run with a model writing queries to the new instruction.

🤖 Generated with Claude Code

2026-10-13 retrieval-augmented-generation #7

Patents companion: list an invention once, with its other publications

patent-fetch now folds the publications of one invention (an application, its grant, the same filing at other offices) into one hit and names the others in also_published_as (polarizetech/patent-fetch@9552d1f).

This makes the patents companion use that:

  • Two planner queries can each keep a different publication of the same invention, so a hit counts as already listed when its number, or any number it was also published under, was listed before.
  • The “Existing patents on this” section prints Also published as ... after an entry (four numbers, then a count).

Why: a pipeline run on 2026-10-13 listed five patents, of which four were the US, EP, WO and CA publications of one Cochlear patent. The same two queries now list two inventions.

Older patent-fetch versions send no also_published_as; the companion then behaves as before.

Checked: ruff, pyright, 250 tests; and the companion run against the live patent services with the queries from that run.

🤖 Generated with Claude Code

2026-10-13 adaptive-preregistration #1

scope-status finds an app version at apps//

The scaffold is moving apps to apps/<slug>/vN/, one folder per app and one inside it per version (polarizetech/scientific-research-scaffold#2). The kit names that layout in one place: the default folder scope-status uses for a [[apps]] entry in STUDY.toml that has no path.

  • An app entry is now looked for at apps/<slug>/<version>, then at the earlier apps/<version>-<slug>.
  • Nothing else in the kit depends on where apps live. Preregistrations are found by their preregistrations/ folder wherever the unit is, and PREREG_PROTOCOL.md already says the layout is the organisation’s convention.
  • A project on the earlier layout behaves as before.

No release in this PR: the changelog entry is under “Unreleased”.

Tests: 51 pass; the manifest test now covers an app in each layout.

🤖 Generated with Claude Code

2026-10-13 scientific-research-scaffold #2

Apps are laid out as apps//vN, each app numbered from v1

An app’s versions now sit together: apps/entropy-media/v1/, apps/entropy-media/v2/. Before, a study had one number sequence and folders named apps/vN-<slug>/, which put unrelated apps side by side in number order and split one app’s versions apart.

What changes

  • scaffold new app <slug> writes apps/<slug>/vN/. A new slug starts at v1; a slug that exists gets its next version.
  • check looks for an [[apps]] entry with no path at apps/<slug>/<version>/, then at the earlier apps/<version>-<slug>/. Repos on the earlier layout pass unchanged (checked against cochlear-mirror and tinnitus).
  • The app template’s serve.py looks one folder further up for the design system.
  • PROTOCOL.md § 1, 2, 3, 5, 6, README.md, ADOPTING.md and the study template’s apps/README.md describe the new layout.

Not in this PR

  • No release: the changelog entry is under “Unreleased”, and SCAFFOLD_REF, UPGRADING.md and the generated CI ref are untouched.
  • No migration command. Existing repos keep their folders; world-seeding already uses the new layout through path entries.
  • The preregistration kit reads the same default in polarizetech/adaptive-preregistration (its own PR). Until both are released, a repo on the new layout needs path in each entry for the kit to find its apps.

Tests: 73 pass (2 new: per-app version numbers, and the earlier layout passing check).

🤖 Generated with Claude Code