GRAFT

AI made writing software cheap. Trusting it is still expensive. GRAFT finds capabilities you’ve already built, checks whether they fit, and proves the result at an exact revision.

Comment

Judge in five minutes

  1. Demo (4:32): a Blocked host refused at 1:18, COMPOSITION VERIFIED at 1:51, the same evidence turning STALE after a later commit at 2:26, and an INCOMPATIBLE refusal with Apply disabled at 3:32.
  2. Judge site: step through the recorded run in the evidence explorer; no install needed.
  3. Executive Brief: four pages covering market friction, architecture, cohort and fiscal design.
  4. GitHub: docs/GALUXIUM-RUBRIC-EVIDENCE.md maps each judging category to the code and tests that support it.

Inspiration

AI made writing software cheap. Trusting it is still expensive. In the 2025 Stack Overflow Developer Survey, 84% of developers use or plan to use AI tools, yet more distrust the accuracy of AI output (46%) than trust it (33%), and 66% cite "AI solutions that are almost right, but not quite". Generation has outrun verification.

The gap shows up whenever a working capability, such as sign-in or feature flags, needs to move into another project. Someone still has to establish what the existing implementation actually does, whether its evidence is trustworthy, whether it fits the destination, what must change, and whether it still works afterwards. Coding agents complete the requested action; they do not answer those questions. We built GRAFT to answer them.

What it does

GRAFT is the trust, reuse and verification layer for AI-assisted software development. It finds capabilities developers have already built, determines whether they fit another project, and verifies the resulting behaviour with evidence bound to the exact revision. Two things make it different: it can refuse unsafe reuse, and its evidence expires when the underlying revision changes.

  • Find it. GRAFT indexes only the folders you authorise, finds capabilities, and shows why it thinks so, file by file. Before remembering a capability, it runs the source project and verifies the behaviour: 13 of 13 required cases for a hosted sign-in, 8 of 8 for a feature-flags library.
  • Fit it. Compatibility Preview classifies a destination as COMPATIBLE, ADAPTABLE or INCOMPATIBLE before anything is written. An incompatible reuse is refused: Apply is disabled and the destination is untouched. A Blueprint (AGENTS.md) hands the exact constraints to whichever coding agent you use, and the Laboratory composes several saved capabilities under explicit dependency, conflict and evidence checks.
  • Prove it. Changes are applied in an isolated git worktree and checked against each capability's own contract. When capabilities are composed, earlier ones are re-verified after later ones are added; COMPOSITION VERIFIED appears only when all pass on one final revision. Evidence is revision-bound: CURRENT at that revision, STALE after the next commit, while the stored proofs stay intact and verifiable offline.

Who it is for. One growing market. AI-native builders can now create substantial software quickly with coding agents; GRAFT gives that workflow memory, compatibility analysis, deterministic refusal, provenance and verification. Professional developers face the same question every time they reuse code they wrote before. Teams accumulate years of proven internal implementations that get rebuilt across repositories; GRAFT turns that work into reusable, evidence-backed capabilities.

Not another coding agent. Agents create or modify software. GRAFT is complementary infrastructure that decides whether existing capabilities can safely fit elsewhere and proves that they do. The agent can change; the knowledge, decisions and evidence stay with GRAFT. No comparison against any coding agent is claimed.

How we built it

  • Core: Node.js, with a CLI, a local browser workspace bound to 127.0.0.1, and an Electron desktop app. All repository-sensitive work is local.
  • Verified harvest: capabilities are detected from source structure and then verified by running the real project over HTTP (or loading the library artifact), with a deterministic stand-in where an external identity provider would be needed.
  • Compatibility: a Host Model of the destination drives the Compatibility Preview; a local Compatibility Atlas records every attempt's evidence and informs risk notes without ever overriding a check.
  • Verification kernel: the vendored CUF proof kernel decides each case, the run verdict and the proof root through a single adapter; GRAFT owns the contracts and observations.
  • Evidence: proof files are tamper-evident (digest-checked), revision-bound and exportable; a Laboratory ledger tracks CURRENT and STALE; a Data Boundary classifies and records any optional agent egress.
  • Hosting and commerce: a static, sanitized judge site on Vercel; the DMG on Tigris object storage; a separate licensing service with Stripe Checkout and Payment Link, signed webhooks and server-side purchase verification (implemented and tested; its Galuxium deployment is not yet live).
  • Repository: the public GitHub repository is a security-reviewed submission mirror of the private development tree, published by the sole developer. The incremental private history (first commit September 7, 2026; none before the July 15 window start) is summarised in docs/GALUXIUM-BUILD-EVIDENCE.md.

Challenges we ran into

  • Keeping every claim honest: VERIFIED means exactly the required cases that passed at an exact revision, and optional witnesses are shown even when they fail.
  • Making refusal a first-class outcome rather than an error path.
  • Making composition trustworthy, since a later capability can break an earlier one.
  • Treating staleness as a state the product tracks, instead of trusting an old checkmark.
  • Recording a demo that is a genuine operation of the packaged app rather than a slideshow.

Accomplishments that we're proud of

  • An end-to-end run in the packaged app: discovery, source verification, refusal of an incompatible host, and a two-capability composition that reaches COMPOSITION VERIFIED on one revision.
  • Evidence that goes STALE after an ordinary later commit while its proofs remain intact and verifiable offline.
  • A public suite of 584 tests (532 passed, 0 failed, 52 skipped on a fresh clone) and a 4:32 demo that is 92.6% live capture.

What we learned

  • Reuse needs behaviour and evidence, not just files.
  • Static detection finds candidates; only execution proves them.
  • A refusal before anything is written is as valuable as a successful transplant.

What's next for GRAFT

  • More capability kinds and host architectures.
  • Shared team registries with policy, governance and audit retention (the proposed recurring tier).
  • A planned, protected benchmark comparing raw repository access with GRAFT's validated capability abstraction. It has not been run and no result is claimed; see the Paper2Agent note in the public docs/GALUXIUM-FINAL-SUBMISSION.md.

Architecture

Discover and verified harvest → Capability Memory and Capability Genome → Compatibility Preview and Compatibility Atlas (refuse, or continue) → Blueprint or Laboratory plan → transplant or composition in an isolated worktree → CUF verification → revision-bound, tamper-evident evidence → Laboratory ledger (CURRENT or STALE). A Data Boundary and custody ledger cover optional agent egress. State is local JSON under GRAFT_HOME; there is no hosted database. The README has a Mermaid diagram and the gallery has the architecture image. Claim-by-claim evidence for each judging category: docs/GALUXIUM-RUBRIC-EVIDENCE.md.

Target users

  • AI-native builders: people building substantial software with coding agents who need reuse and verification to keep pace with generation.
  • Professional software developers: engineers who want to reuse code they already wrote without re-deriving whether it still works.
  • Teams with proven internal implementations: organisations, including security-conscious or regulated ones, that need auditable reuse and AI-assisted change.

There are no current enterprise customers.

Monetization

Implemented and tested: the licensing service for a $49 USD one-time desktop licence: Stripe Checkout with Managed Payments requested (Stripe acts as merchant of record); a /buy redirect to a Stripe Payment Link; signature-verified webhook fulfilment, including refund revocation; server-side purchase verification that re-fetches the Checkout Session and checks the exact price, product, amount and quantity before any licence is issued (a success redirect alone never issues one); and licence activation, validation and deactivation with per-installation seats. Covered by 110 automated tests against a Stripe fake.

Configured, not live end to end: a Stripe test-mode product, $49 price, Payment Link (Managed Payments, Stripe-calculated tax, Stripe-issued invoices) and webhook. The licensing service that fulfils them is not yet deployed, and no purchase has been completed through it. Sandbox transactions are test data, not revenue.

Roadmap (not implemented): individual developers buy the desktop product; teams later pay recurring fees for a shared capability memory and registry, organisational policy, governance, audit retention and verification infrastructure; enterprises add identity and access controls, private deployment and support. No revenue, customers or usage figures are claimed.

Links

Share this project:

Updates

Submission history