SuperAPI AI Directory

Derivative

Open-source AI-assisted engine for greenfield requirement-to-software synthesis with typed requirement preservation, isolated execution, independent evidence-based validation, bounded repair, and fail-closed packaging.

Open website

About this tool

Derivative is an open-source AI-assisted engine focused on synthesizing executable software directly from natural language requirements. Its software build pipeline is called Forge, and its goal is not simply to generate seemingly plausible implementations and return them, but to answer a stricter question: what evidence is sufficient to prove that the generated software is acceptable. Therefore, Forge converts natural language requirements into typed obligations, executes candidate code outside the generator, has it checked by an independent verifier, constrains the repair process by observed failures, and fails closed rather than optimistically packaging claims that cannot be supported.

Purpose

Derivative is aimed at scenarios that need to introduce a verifiable chain of evidence in the "requirements-to-software" process. It is not satisfied with generating code; instead, it requires candidate implementations to satisfy executable requirements, run successfully in a sandbox, pass independent checks, and produce sufficient evidence before packaging is allowed.

Main capabilities

  • Requirement preservation: hard, ambiguous, and general requirements can be traced from the source text to plans, files, tests, assertions, and verification evidence.
  • Quality contracts: commitments such as security, persistence, rate limiting, auditability, observability, and test depth can be converted into executable obligations.
  • Isolated execution: production verification runs in temporary Docker containers, with no network, a read-only root filesystem, resource limits, and an environment allowlist.
  • Independent verification: syntax/import/run, obligation/acceptance, and adversarial checks must all pass.
  • Bounded repair: retries target observed failure signatures and must produce substantive artifact changes before re-verification.
  • Oracle preflight: inconsistent external benchmarking frameworks terminate with oracle_invalid before Forge or the model executes.

Usage

Prerequisites: Python 3.11 and Docker. Docker is used for production verification of generated code. Deterministic artifacts can be generated and verified without an API key: (No specific command is provided in the material) Enable model-supported candidate compilation and repair: (No specific command is provided in the material) Host credentials are not inherited by the generated code sandbox. The CLI reports terminal status, executed phases, verification results, artifact paths, repair counts, trace seals, and elapsed time. Build the sandbox for Docker-supported integration and benchmark runs: (No specific command is provided in the material) Installation profiles: install only the required capabilities; requirements.txt is a compatibility alias for requirements/all.txt. Missing selected runtimes fail explicitly at their capability boundaries.

ApplicableScenarios

  • Brand-new Python CLI, REST services, data pipelines, and library artifacts.
  • Deterministic capability configuration with model-supported degradation fallback.
  • Typed public modules and symbol contracts.
  • Requirement-level tests and assertion evidence.
  • Docker-isolated verification and independent black-box benchmark oracle.
  • Explicit infeasibility certificates and invalid benchmark rejection.

Limitations

  • No support for general existing repository editing.
  • No support for other programming languages or frontend generation.
  • No support for formal verification of arbitrary software.
  • No support for general semantic coverage beyond implemented contracts.
  • No distribution of wheels, runtime containers, SBOMs, or supply chain attestations.

Meaning of Verification

verified does not mean formal proof or universal correctness. It only means that at that revision, the generated artifacts satisfy the compilation requirements, quality, execution, and adversarial contracts that Forge knows how to check. Independent blind oracle acceptance is measured separately. Unsupported or unproven behavior should end with validation_failed and should never be optimistically packaged.

Benchmark Evidence

Forge's CI run for b541ec7 passed 711 tests on Linux/Python 3.11 on September 30, 2026. The workflow also runs a minimal runtime smoke check and a Docker-backed extended benchmark quality gate. The project intentionally separates internal verification from external blind acceptance. Frozen blind benchmarks are never retroactively rescored after fixes. The latest frozen blind baseline is V11, a schema-4 bundle containing 12 cases: status accuracy 6/12; external Verified@1 is 0/6; three expected validation_failed cases and three infeasible cases all match their labels. V5–V11 are the known benchmark corpus; post-fix replay is regression evidence, not a new blind result. V8-005 is for regression only and must not be reported as new blind evidence. V12 has no published bundle or baseline. The full record is in Benchmark Evidence.

Technical Reference and Project Direction

The technical reference covers contracts, capabilities, verification, repair, isolation, dependencies, and artifact schemas. The current phase is deliberately narrow: preserve frozen evidence, fix structural mechanisms rather than known cases, and evaluate the unchanged system only on new blind distributions once the repair and evidence pipeline is stable. Closing this phase does not require new domains, languages, frontends, or existing repository modes. Derivative is released under the MIT License.