shredbx logo
shredbx shredbx shredbx shredbx Personal
  • Home
  • Lab
  • Portfolio
  • Experience
  • Services
  • Profile
  • Contact
AClaude
  • Home
  • Lab
  • Portfolio
  • Experience
  • Services
  • Profile
  • Contact
Andrei Solovev
Knowledge
Search knowledge... ⌘K
Knowledge · Rules · Development

Contract First Recursive Design

Every design task is built outside-in: define the top-level contract BY EXAMPLE (input fixtures + expected outputs, including adversarial 'break it every way') BEFORE designing internals; stress-test and simplify; lock the simplest contract; then decompose one level down and RECURSE to the final primitive. Two gates apply at every step: never proceed below 90% confidence without asking; never fabricate data.

Andrei Solovev

Tags

rule

Overview

Purpose

Every design task is built outside-in: define the top-level contract BY EXAMPLE (input fixtures + expected outputs, including adversarial 'break it every way') BEFORE designing internals; stress-test and simplify; lock the simplest contract; then decompose one level down and RECURSE to the final primitive. Two gates apply at every step: never proceed below 90% confidence without asking; never fabricate data.

Rules

CFR-001: Contract by example FIRST. Before designing any internals at a given level, write the top-level input fixtures and their expected outputs AS IF the system already works — including adversarial scenarios that try to break it every possible way.

The external contract is the specification. Designing internals before the contract is locked builds on sand. Adversarial examples expose ambiguity and missing decisions early, when they are cheap to fix.

Verification: A fixtures artifact (input -> expected output|error) exists and covers happy path + adversarial classes BEFORE any internal/architecture design for that level.

CFR-002: Stress and simplify, then LOCK. Analyse the fixtures: is the contract optimal, or can the integration be simpler? Fewer concepts win. Only then lock the simplest contract that covers the fixtures for this level.

The first contract is rarely the simplest. Simplification before lock prevents carrying accidental complexity into every layer below.

Verification: An analysis records the redundancies/simplifications considered; the locked contract is the simplest that still covers the fixtures.

CFR-003: Decompose one level down only AFTER the contract is locked, then RECURSE: for each internal component, repeat CFR-001..CFR-002 (its own contract by example) down to the final primitive. Review before descending further.

Recursive contract-first keeps every layer proven against its own example set (Base -> Test -> Wrap -> Expand). A layer is decomposed only once its contract is locked.

Verification: Each decomposed component has its own locked contract + fixtures before its internals are designed.

CFR-004: CONFIDENCE GATE — if confidence in ANY required input or decision is below 90%, STOP and ask the user. Never proceed on assumption. Prefer a question over a guess.

An unstated assumption silently corrupts everything built on it. Asking is cheap; rework is not. The user is the authority on intent.

Verification: No design decision is recorded as 'decided' while sub-90% confidence and unasked. Open questions are surfaced as questions, not resolved silently.

CFR-005: NO-FABRICATION GATE — produce 0% fabricated data. Never invent fixture values, examples, names, facts, or defaults without a direct user request. If fabrication is unavoidable because user input was insufficient, REPORT it explicitly with root cause ('generated X because the request lacked Y').

Fabricated data masquerades as fact and propagates. Reporting the root cause turns a silent guess into a visible request for the missing input.

Verification: Every example/fixture value traces to user input or a direct request. Any generated-without-request data is flagged with its root cause in the same response.

shredbx logo shredbx shredbx shredbx shredbx Andrei Solovev

Solution Architect & Lead Software Engineer

ExperiencePortfolioResearch & ExperimentsEducationCertificationSkills
GitHub ↗LinkedIn ↗Email ↗
AVAILABLE FOR NEW PROJECTS
// MY LATEST BEATS
Hobby & Interests

Lab

  • The Lab
  • Framework
  • Components
  • Packages
  • Games
  • Process (SDLC)
  • Knowledge
  • Blog

Andrei

  • Portfolio
  • Experience
  • Services
  • Profile
  • Contact
  • Lifestyle

Team

  • Team
  • Andrei
  • Claude

Legal

  • Privacy
  • Terms
  • Cookies
© 2026 shredbx.com. All rights reserved. — Andrei Solovev |