Files
openprose__prose/packages/std/composites/contrastive-probe.md
irl-dan 63c8ce4b23 Migrate std and co into packages/ monorepo layout
Move the standard library (previously `github.com/openprose/std`) and
the company-as-prose library (previously local dir
`/Users/sl/code/openprose/company-as-prose`) into this repository
under `packages/std/` and `packages/co/` respectively.

Motivation: concentrate attention on one repository so stars,
discussions, and issues aggregate. `openprose/std` was a genuinely
useful asset nobody could find because ~50 stars on its own repo
told a much worse story than 1,106 stars on `openprose/prose`
would have. Same logic applies to co.

Layout choice: `packages/{std,co}/` rather than `std/` + `co/` at
the repo root. Root siblings accumulate over time, and a flat
top-level made future libraries (hub, kit, dev, etc.) compete with
spec infrastructure. `packages/` is bounded — new libraries land
there without cluttering root. Matches pnpm/Deno/monorepo tooling
conventions.

Changes:

- New: `packages/std/` (copied from openprose/std, `.git` excluded)
- New: `packages/co/` (copied from company-as-prose, README updated
  for new name and location)
- `packages/std/README.md`: updated shorthand expansion reference
- `packages/co/README.md`: renamed "company-as-prose" to "co" in
  self-references, added std-vs-co split heuristic, updated
  `prose run` examples to use `co/` shorthand
- `skills/open-prose/deps.md`:
  - `std/` shorthand now expands to
    `github.com/openprose/prose/packages/std/`
  - `co/` shorthand added, expands to
    `github.com/openprose/prose/packages/co/`
  - Both shorthands resolve into the same clone of
    `openprose/prose` under `.deps/github.com/openprose/prose/`;
    `packages/std/` and `packages/co/` are sibling subdirectories
  - `prose.lock` format row updated to `host/owner/repo sha`
    (matches the explicit-host resolution that landed in #35)
  - `.deps/` directory structure example redrawn to show the
    `{host}/{owner}/{repo}/packages/{std,co}/...` shape
  - Error message and Interaction tables refreshed accordingly
  - Resolution Algorithm step 1 now documents both shorthands
- `skills/open-prose/forme.md`: Step 2 resolution list updated to
  include co/ shorthand and the host-keyed `.deps/` layout
- `skills/open-prose/help.md`: Q&A "How do dependencies work?"
  rewritten to name both shorthands and the new explicit-host model
- `skills/open-prose/state/filesystem.md`: `.deps/` directory
  tree re-drawn to include the `{host}/` layer with std/co as
  sibling packages inside the clone
- `skills/open-prose/guidance/patterns.md`,
  `skills/open-prose/guidance/antipatterns.md`: examples now use
  the `std/` shorthand or explicit `github.com/...` rather than
  the deprecated bare `openprose/std/` form
- `skills/open-prose/examples/registry-import/index.md`: sample
  service reference switched to `std/evals/inspector`
- `README.md`: Stdlib badge replaced with internal `packages/std/`
  link plus new `packages/co/` link; "Standard Library" section
  rewritten as "Libraries" with both packages described

Out of scope for this PR (deliberately):
- Tooling changes to `prose install` and Forme's `.deps/` writer
  to adopt the `{host}/{owner}/{repo}/` layout in practice — this
  PR is spec-only. Existing tooling continues to work against
  whatever layout it currently implements; the spec now describes
  the target.
- Retiring the `openprose/std` GitHub repo. Delete that repo
  separately after this merges.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 14:14:31 -07:00

5.1 KiB

name, kind
name kind
contrastive-probe composite

Contrastive Probe

A meta-composite. Run any read-only measurement on two candidate artifacts, then rank which scores better on the measured dimension.

Description

Runs any measurement composite on two candidates independently, then ranks which scores better on the measured dimension.

Metadata

  • version: 0.1.0

Slots

  • measurement (primary)
    • requires: candidate_config
    • ensures: diagnostic_profile
  • ranker
    • requires: profile_a, profile_b, dimension
    • ensures: verdict, magnitude, evidence

Config

  • dimension (string, default: none): The quality being compared (e.g. "clarity", "determinism", "assumption count")
  • candidate_a (string, default: none): First candidate configuration
  • candidate_b (string, default: none): Second candidate configuration
  • label_a (string, default: Candidate A): Human label for the first candidate
  • label_b (string, default: Candidate B): Human label for the second candidate

Invariants

  • The same measurement composite runs on both candidates
  • Candidates are measured in isolation — measurement of A does not influence B

Shape

  • self: run the same measurement composite on candidate A and candidate B, delegate ranking
  • delegates:
    • measurement: any read-only measurement composite — blind-review, stochastic-probe, assumption-miner, etc.
    • ranker: given two diagnostic profiles, determine which candidate is superior on the measured dimension
  • prohibited: none

Requires

  • &compositeState exists at __compositeState with: measurement: string -- component name for the measurement composite to use ranker: string -- component name for the ranker candidate_a: object -- compositeState config for measuring candidate A (passed to measurement composite) candidate_b: object -- compositeState config for measuring candidate B (passed to measurement composite) label_a: string -- (optional, default "Candidate A") label_b: string -- (optional, default "Candidate B") dimension: string -- what is being compared (e.g. "clarity", "determinism", "assumption count")

Ensures

  • The same measurement composite runs independently on both candidates
  • Candidates are measured in isolation — the measurement of A does not influence B
  • Ranker receives both diagnostic profiles and the dimension to judge
  • Ranker determines:
    • Which candidate scores better on the specified dimension
    • By how much (qualitative magnitude: marginal, clear, decisive)
    • What specifically makes one better than the other
  • &compositeState.result contains the ranker's verdict
  • &compositeState.profile_a contains candidate A's measurement result
  • &compositeState.profile_b contains candidate B's measurement result

Delegation Loop

const {
  measurement, ranker,
  candidate_a, candidate_b,
  label_a = "Candidate A", label_b = "Candidate B",
  dimension
} = __compositeState;

// Run measurement on candidate A
const profileA = await rlm(null, null, {
  use: measurement,
  compositeState: candidate_a
});

// Run measurement on candidate B
const profileB = await rlm(null, null, {
  use: measurement,
  compositeState: candidate_b
});

// Ranker compares
const rankerBrief = `Two candidates were measured on the same dimension using the same diagnostic instrument.

Dimension: ${dimension}

=== ${label_a.toUpperCase()} — Diagnostic Profile ===
${JSON.stringify(profileA, null, 2)}

=== ${label_b.toUpperCase()} — Diagnostic Profile ===
${JSON.stringify(profileB, null, 2)}

Determine:
1. Which candidate scores BETTER on "${dimension}"?
2. By how much? (marginal / clear / decisive)
3. What specifically makes one better? (cite evidence from the profiles)
4. Are there sub-dimensions where the losing candidate is actually superior?`;

const verdict = await rlm(rankerBrief, null, { use: ranker });

__compositeState.result = verdict;
__compositeState.profile_a = profileA;
__compositeState.profile_b = profileB;
return(verdict);

Notes

This is a seed pattern and a meta-composite — it composes over other measurement composites rather than implementing its own measurement logic. The ranker does not know it is part of a contrastive probe. The measurement composite does not know it is being used comparatively.

The value is in making qualitative comparisons empirical. "Which of these two prompts is clearer?" is a subjective question. "Which of these two prompts produces a higher cross-tier agreement score on blind-review?" is a measurable one. Contrastive probe turns any measurement composite into a comparator, enabling:

  • Prompt A/B testing: which prompt is more deterministic (via stochastic-probe)?
  • Documentation quality comparison: which version is clearer (via blind-review)?
  • API surface ranking: which interface has fewer hidden assumptions (via assumption-miner)?
  • Vendor evaluation: which provider's documentation drifts less from their actual API behavior (via coherence-probe)?

The meta-composite pattern also means new measurement composites automatically become available as contrastive dimensions without any additional work.