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

Loading full source files during discovery exhausts model attention and causes middle-rule drop. Baltor separates discovery from materialization using typed contract cards under 2,048 bytes.

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) on foundry.baltor.ai.

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

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

{
  "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), 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.