- Similar work is performed again for each task.
- Capacity grows mainly by adding human time.
- Process knowledge may remain informal.
Partner brief
Build the commercial path for a verification-first task factory.
FaultWright is being built to autonomously execute permitted software-engineering AI-training tasks, independently verify the result, and produce auditable evidence. Demo V0 proves the verification core; the wider execution system is under active development.
The first marketplaces give us real work to prove the system against; they are not the product we are trying to build.
What FaultWright does
Real workloads become verified outputs—and reusable system capability.
FaultWright is intended to receive permitted software-engineering AI-training tasks, normalize their instructions and acceptance requirements, plan the work, and execute supported task families with as little human intervention as the task safely allows.
The solver does not certify itself. FaultWright independently verifies the result, checks for failure modes or shortcuts, retries when the evidence supports it, and packages the outcome for review.
The current public demo proves that verification layer under one frozen repair task. It does not yet prove autonomous intake and execution of external platform tasks.
- 01
Permitted workload
A real task whose rules allow the planned automation and data handling.
- 02
Intake and plan
Normalize instructions, acceptance requirements, environment, and execution steps.
- 03
Autonomous execution
Perform the supported engineering work and escalate unsupported or ambiguous cases.
- 04
Independent verification
Evaluate, critique, retry if warranted, and package auditable evidence.
Proving ground vs. product
The work is the input. The reusable system is the asset.
Early platform tasks matter because they expose FaultWright to real requirements, rejection criteria, and operating constraints. Repeated work should become shared product capability rather than staying informal task knowledge.
- Execution logic becomes reusable software.
- Human intervention should decline across repeated, supported task families.
- Independent verification is part of the system.
- Each outcome can improve shared infrastructure.
The first marketplaces give us real work to prove the system against; they are not the product we are trying to build.
Current state
Where things stand
A precise picture of the present, so the conversation can start from the same facts.
- Verification core
- Built
- Demo V0 shows discriminative verification, canonical outcomes, evidence, and artifact integrity.
- Autonomous task factory
- In development
- External intake, normalization, planning, execution, critic / retry, and result packaging are the active build direction.
- Platform / task coverage
- Selective
- Not every platform or software-engineering task family is supported. Permission and compliance are required gates.
- Commercialization
- Beginning
- The first target is permitted platform workloads that provide real feedback and early revenue.
- Paying customers
- None to date
- No revenue or adoption is claimed.
- Formal company
- Not yet formed
- Founder-led project. A formal entity would follow if the work warrants it.
Why another person is useful
The product owns technical execution. The collaborator opens and interprets the market.
I own the FaultWright system and technical execution. The collaborator helps find more high-value tasks for current step.
System / technical execution
Founder
- Task intake, normalization, and execution architecture
- Solver orchestration, environments, and supported automation
- Independent verification, critic behavior, retry logic, and evidence
- Turning repeated workload patterns into reusable product capability
- Technical delivery and engineering decisions
- Submission of a high-quality, flawless deliverable
Workloads / commercial operations
Collaborator
- Find relevant AI-training and software-engineering workload sources
- Understand platform and customer rules
- Identify task families compatible with FaultWright
- Support communication, contracts, and payment operations
- Secure more paid work from platforms ultimately
No coding is required.
Technical contribution is welcome where it is genuinely useful, but it is not the role. This is a securing high-value paid contracts role—not recruitment for a manual task-delivery team.
Initial revenue arrangement
A project-level model for the paid proving ground
For early paid platform or customer work that we bring in together, the current proposal is to split collected project revenue 50/50 after any mutually agreed direct project expenses.
This applies to early project revenue while real workloads validate the reusable FaultWright system. If FaultWright develops into a formal company, long-term company ownership and economics would be discussed separately.
Technical proof
Demo V0 proves the verification core
The frozen record below demonstrates independent repair evaluation and auditable evidence. It does not claim autonomous intake or execution of an external platform task.
Demo V0 publishes
- Task identity: task ID, environment, fingerprint
- Controlled pipeline-validation attempts
- Verification outcomes and capability verdicts
- Evidence references and attempt identifiers
- Artifact digests verified at build time
- Independently inspectable JSON records
Evaluation recordDemo V0
Frozen · 2026-09-28Webhook idempotency: duplicate deliveries must not duplicate invoices
IF-WEBHOOK-00001webhook 1.0.0run 879c077fcda2
- PASS · SOLVED
Reference Repair
Positive control · patch
94b5e86d…15ca99 - FAIL · NOT_SOLVED
No Repair
Negative control · no patch
sha256 verified at buildFull evidence ledger
Questions
Likely questions, answered plainly
Is FaultWright already working?
The verification core is working at demonstration scale. Demo V0 is one complete frozen evaluation with pipeline controls, verified outcomes, and hashed artifacts. Autonomous external task intake and execution are under active development.
Do I need to code?
No. The useful contribution is commercial and operational: finding workload sources, understanding rules, identifying compatible tasks, supporting relationships and payments, and returning external feedback to the product.
Is this an outsourcing operation?
Early workloads may arrive task by task, but the objective is to move repeated execution, verification, retry behavior, and evidence generation into reusable software.
Are there paying customers already?
Not yet. Existing platforms are the intended near-term entry point because they contain real workloads and acceptance feedback. No revenue, direct task stream, or guaranteed demand is claimed today.
Why focus on the US market?
Many relevant AI-training platforms, labs, and data vendors operate in the US market. A US-side collaborator can better understand their rules, workload needs, time zones, contracts, and payment operations.
Is FaultWright already a company?
No. It is a founder-led project. If it develops into a formal company, ownership and economics would be discussed separately from the initial project-level revenue arrangement described above.
Next step
Interested in the product direction?
If this path matches your commercial background, the next step is simply a conversation about workload sources, platform rules, the initial project model, and whether there is a useful way to work together.