# Why Every Baltor Capability Starts as a < 2 KB Contract Card Before Loading Source

Published: 2026-10-18 | Category: Context Architecture | Live Surface: https://foundry.baltor.ai

## Outcome first: eliminating middle-context constraint drop

When a coding agent is handed 15,000 tokens of raw library source code and documentation during task planning, its adherence to middle specification constraints drops sharply. In our 14-constraint engineering benchmark on `gemma4:31b`, loading full reference source up front resulted in a `42.9%` pass rate (6 of 14 rules satisfied, with 8 middle rules silently omitted). Replacing upfront source dumps with compact contract cards under `2,048` bytes raised adherence to `100.0%` (14 of 14 rules verified) while cutting prompt token consumption by `78.4%`.

## Separating discovery from materialization

In Loop Engine, discovery is strictly effect-free. A model exploring a catalogue of over one million served component files never pulls implementation source bytes just to decide whether a capability fits a task. Instead, the harness queries compact contract cards (`baltor_contract_card.json`).

Each contract card is capped at `2,048` bytes and states six machine-checkable fields:

1. **`component_id` and `schema_version`**: Immutable identifier and pre-launch handshake version.
2. **`engine_slot`**: The functional slot in `engine_slots.yaml` that owns execution.
3. **`input_ports` and `output_ports`**: Exact JSON Schema types for incoming and outgoing edge payloads.
4. **`refusal_codes`**: Explicit typed failure codes returned before any external effect if preconditions fail.
5. **`required_authority`**: Declared file, network, shell, or model permissions required at execution time.
6. **`verification_gate`**: Content hash (`sha256`) of the conformance check that validates output.

```json
{
  "schema_version": "baltor.contract_card.v1",
  "component_id": "creative.mesh.manifold_repair.v1",
  "engine_slot": "mesh_manifold_verifier",
  "byte_size": 612,
  "input_ports": {
    "vertices_f32": "Float32Array[N*3]",
    "indices_u32": "Uint32Array[M*3]"
  },
  "output_ports": {
    "is_manifold": "boolean",
    "boundary_edges": "integer",
    "flipped_normals_fixed": "integer",
    "euler_characteristic": "integer"
  },
  "refusal_codes": [
    "degenerate_zero_area_triangle",
    "non_manifold_edge_valence_gt_2",
    "unindexed_ soup_exceeds_vertex_budget"
  ],
  "required_authority": ["compute_only"],
  "verifier_sha256": "9f84c2e18b407d6a1a52c871e9b4d0f32e1a6c8b70e4f912a3d5c6b7e8f901a2"
}
```

## Factorized context: H_gen plus H_env

In our Harmony Pareto evolution study ([harmony.baltor.ai](https://harmony.baltor.ai)), we formalize working memory as the direct sum of transferable safety and structural invariants (`H_gen`) and task-specific environment bindings (`H_env`). Contract cards keep `H_env` bounded during graph assembly. Once the model composes and orders the required capability cards into a solution graph, the runtime materializes source bytes only for the selected vertices and preserves unchanged implementations across revisions instead of paying to generate them again.