Integrations

Bayesilisk integrations are optional. The deterministic CLI remains usable with standard-library Python only.

For app-specific adapters, see Connector Authoring. Connector code belongs in the target app or test repo. Test teams should not patch Bayesilisk core to support one application.

Microsoft Playwright

The Playwright bridge turns browser observations into Bayesilisk context JSON.

Install:

python3 -m pip install -e '.[playwright]'
python3 -m playwright install chromium

Run the local demo:

bayesilisk-demo
python3 tools/playwright_probe.py --demo --output /tmp/bayesilisk-playwright-context.json
python3 -m bayesilisk --seed 150 --context /tmp/bayesilisk-playwright-context.json --format json

bayesilisk-demo serves an intentionally brittle local workflow app and prints this chain:

Playwright evidence
  -> Grassmann plane
  -> optional model-style proposal
  -> deterministic verdict
  -> issue payload

It can run with --no-playwright when a tester wants deterministic local evidence without launching Chromium.

Capture evidence artifacts:

python3 tools/playwright_probe.py --demo \
  --artifacts-dir /tmp/bayesilisk-artifacts \
  --screenshot \
  --trace \
  --output /tmp/bayesilisk-playwright-context.json

The probe looks for rows marked with data-bayesilisk-probe. Each row should provide:

• data-title;

• data-actor-role;

• data-route;

• data-invariant-id;

• data-expected-status;

• clickable child data-run-probe;

• status child data-observed-status.

Playwright is the sensor. Bayesilisk remains the judge.

Ollama Embeddings

Embeddings add a similarity signal to Grassmann attention:

BAYESILISK_USE_OLLAMA_EMBEDDINGS=1 \
BAYESILISK_OLLAMA_MODEL=nomic-embed-text \
python3 -m bayesilisk --seed 150 --context /tmp/context.json --format json

If Ollama is unavailable, the dependency-free anchor-plane proxy is still used.

Scenario Proposer Model

The default proposer provider is Ollama:

BAYESILISK_USE_OLLAMA_SCENARIO_MODEL=1 \
BAYESILISK_OLLAMA_SCENARIO_MODEL=gemma4:e2b \
python3 -m bayesilisk --seed 150 --context /tmp/context.json --format json

The provider boundary is explicit. BAYESILISK_SCENARIO_PROVIDER defaults to ollama; openai-compatible is available for hosted Chat Completions style endpoints. API keys come from BAYESILISK_SCENARIO_API_KEY, provider-specific environment variables, or the variable named by BAYESILISK_SCENARIO_API_KEY_ENV. Reports include provider/model/proposal provenance and key-presence booleans, but never raw keys or sensitive headers. Provider output stays untrusted and schema-validated. Configuration precedence is explicit CLI/MCP arguments, then environment variables, then defaults.

Environment variables are not required for reproducible runs. The CLI also accepts explicit controls:

python3 -m bayesilisk --seed 150 --context /tmp/context.json \
  --enable-embeddings \
  --embedding-model nomic-embed-text \
  --enable-scenario-proposer \
  --scenario-provider ollama \
  --scenario-model gemma4:e2b \
  --scenario-proposal-limit 3 \
  --attention-threshold 0.4 \
  --attention-selection-limit 3 \
  --ollama-base-url http://localhost:11434

Reports include effectiveConfiguration, so a tester can see which attention, embedding, provider, model, proposal-limit, key-presence, and base-URL-class settings were actually used.

Live verification is opt-in:

python3 -m pytest -m live_playwright
BAYESILISK_LIVE_OLLAMA=1 BAYESILISK_OLLAMA_SCENARIO_MODEL=gemma4:e2b python3 -m pytest -m live_ollama

The GitHub CI workflow skips live Playwright and live Ollama tests by default, because it does not assume installed browsers or a local model service.

MCP Server

Bayesilisk includes a local stdio MCP tool server:

bayesilisk-mcp

From a checkout, the module form is equivalent:

python3 -m bayesilisk.mcp_server

By default the server writes only MCP JSON-RPC frames on stdout and stays quiet on stderr. Set BAYESILISK_MCP_BANNER=1 when running it manually if you want the ASCII startup banner.

Verifier tools:

• run: run a contextual report.

• rank_context: return ranked failed probes from supplied context.

• issue_payloads: return deduped issue payloads for ready failed findings.

• propose_probes: expand connector-supplied rules and action graphs into probe proposals.

Codex orchestration tools:

• interview_connector_need;

• establish_provenance;

• connector_prompt_packet;

• scenario_plan;

• verify_connector_outputs;

• fix_packet.

The MCP tools accept the same control names as JSON arguments: enableEmbeddings, embeddingModel, enableScenarioProposer, scenarioProvider, scenarioModel, scenarioProposalLimit, scenarioBaseUrl, scenarioApiKeyEnv, attentionThreshold, attentionSelectionLimit, and ollamaBaseUrl.

The MCP server runs locally and does not mutate issue trackers or production systems.

For Codex configuration and connector onboarding, see Codex MCP.

Coding Agent Loop

A Codex-style agent can use Bayesilisk MCP as the cheap local drill layer:

1. Call interview_connector_need.

2. Call establish_provenance.

3. Call connector_prompt_packet.

4. Write connector code and source context in the target app or test repo.

5. Call scenario_plan or propose_probes.

6. Run the app-specific connector against local fixtures.

7. Call verify_connector_outputs.

8. Call fix_packet only for verified issue-ready findings.

If a local model/API is configured, pass enableScenarioProposer=true plus scenarioProvider, scenarioModel, and base URL/API-key settings to run. Model proposals stay untrusted; Bayesilisk validates them before deterministic verification.

GitHub Issues

The repository uses GitHub Issues for public planning. Bayesilisk itself emits issue-ready payloads, but creating issues is intentionally left to a caller-controlled workflow.