Skip to content

Purpose

Sasha Lopashev edited this page Jul 20, 2026 · 21 revisions

Purpose

The problem

Mainstream programming languages are optimized for humans to prescribe procedures. Coding agents can generate those procedures quickly, but prose tickets, source code, policy, and evidence often remain separate—and a plausible implementation can quietly satisfy the visible tests while changing the intended meaning.

BHCP explores a different contract: declare outcomes, authority, limits, effects, preferences, and acceptance evidence in one typed semantic model. An implementation may choose how to achieve a goal, but it must not erase obligations, invent authority, or claim acceptance without the named evidence.

Who it is for

  • People and organizations delegating consequential work to coding or execution agents.
  • Tool builders who need deterministic intent artifacts, stable identities, and independently checkable evidence.
  • Language and verification researchers testing whether semantic contracts improve correctness and claim calibration.

Proposed value

The project is trying to make four properties executable:

  1. Intent survives representation changes. Formatting, comments, labels, and safe custom layouts do not change semantic identity.
  2. Authority only narrows downward. Organization, team, repository, and user policy layers compose monotonically; a later layer cannot casually weaken an earlier one.
  3. Behavior grows outside the trusted core. Standard goal algebra is checked-in BHCP prelude source over a tiny behavior-neutral kernel.
  4. Completion is evidence-bound. “Implemented,” “verified,” and “accepted” are different states, and operational faults are not disguised as semantic rejection.

These are design commitments and active implementation targets—not proof that BHCP is already objectively superior to Python, TypeScript, Rust, or other general-purpose languages.

The first property is now demonstrated by a checked-in symbolic layout and a spaced narrative layout for the same policy-governed goal. They retain different profile, comment, label, formatting, AST, and IR artifact identities while sharing the same resolved overlay and semantic identity. A meaningful overlay change breaks that equivalence, so the evidence distinguishes presentation freedom from policy changes. The Phase 4 completion audit binds three acceptance claims for each issue #41–#49 to named checked-in tests and verifies the evidence links and explicit non-goals. This completes the bounded presentation milestone without claiming a complete BHCP v0.

The Phase 2 completion audit makes the same distinction for coding-agent evidence. Historical pilots remain replayable artifact records, invalid and excluded controller runs retain those classifications, and the two hardened registered model studies remain valid 0/5 and 0/1 negatives. The exact adapter integration accepts the focused candidate, but positive in-session model acceptance and any broad BHCP-versus-prose advantage remain unproven. Those residual questions are no longer implicit caveats. The reviewed preregistration and resource decision in #91 freezes a four-task registered-use study and a three-task representation comparison. Positive-use execution #92 is claimed; comparative execution #93 is ready.

Success measures

  • Canonical and presentation-varied sources lower to deterministic, schema-valid artifacts with the expected identity invariants.
  • Standard behaviors are self-hosted without new behavior-specific Rust primitives.
  • Layered policy rejects every unauthorized weakening with stable diagnostics.
  • Coding-agent evidence records pin their reproducible boundary, distinguish historical replay from hardened registration, and remain honest about ties, overhead, variance, exclusions, and failures.
  • Registered adapters can move an exact obligation from source to independently accepted evidence without adding manifest authority; positive model use of that path remains a measured research question.

Non-goals for the current roadmap

  • A complete planner, distributed executor, mutable latch subsystem, or unrestricted agent backend.
  • Arbitrary grammar plugins, macros, parser callbacks, or profiles that can change core meaning.
  • Treating hidden tests as semantic authority or using a skill as a second language specification.
  • Claiming broad productivity or correctness advantage from a small number of intentionally narrow pilots.

Read the vision for the long-term product direction and SEMANTICS for normative v0 behavior.

Clone this wiki locally