Platform documentation portal

Jaysearch

Jaysearch

Governed toolchain nodes for research, planning, and execution.

Jaysearch turns uncertain project work into explicit graph nodes, evidence packets, governed contracts, ranked implementation attempts, and applied solutions.

Design

Capture unresolved problems, critique the workflow, and convert ambiguity into explicit questions before implementation starts.

Research

Attach sources and evidence to questions, options, and scoring decisions so the system can explain why a path was selected.

Plan

Represent work as problem nodes, options, and execution units that can be ranked, reorganized, and linked into DAGs.

Execute

Run the ERA loop: candidate patches, attempts, evaluations, selection, solution artifact emission, and governed application.

Demo Path

Run the graph-to-execution demo

The current demo uses fixture candidate DAGs, selects the best graph, materializes execution units, and runs one metadata-only ERA smoke path.

bin/run-jaysearch-demo --root .

This proves the orchestration bridge. It does not claim autonomous code synthesis or production task completion yet.

Question To DAG

Turn a problem into a graph plan

The interview demo accepts a question, emits bounded evidence, creates candidate DAGs, selects one, materializes execution units, and stops at the implementation boundary.

bin/run-jaysearch-question-dag-demo --root . --question "How should we build candidate generation?"

The emitted run includes machine-readable packets plus a local demo.html presentation view. Live autonomous research and code generation remain explicit next slices.

Open the public demo narrative

ERA Loop

How execution is governed

The execution loop is deliberately packet-based. Research and planning produce a selected graph and execution units. The executor then materializes candidate patches, evaluates attempts, selects a winner, emits a solution artifact, and applies only through a governed boundary.

  1. Candidate graph selection. Competing DAG plans remain visible; the chosen graph records rejected alternatives and selection evidence.
  2. Execution-unit materialization. A selected DAG becomes concrete execution-unit packets with inputs, outputs, validation gates, and completion evidence requirements.
  3. Candidate patch production. Patch candidates are represented explicitly with patch refs, metadata, and blockers instead of being hidden inside prose.
  4. Attempt evaluation and selection. Attempts are scored from command results and evidence, then a deterministic selection step chooses the solution artifact.
  5. Governed apply. Applying a solution is a separate state transition with post-apply validation and follow-up problem capture.

Operating Boundary

What this repo does and does not claim

The repo can turn bounded questions into graph plans, materialize execution units, rank supplied patch candidates, evaluate attempts, and apply selected solutions in an isolated target. It does not yet claim unconstrained autonomous code synthesis or production task completion without human governance.

Open the platform tool inventory

Node Graph

How the toolchain is supposed to work

flowchart TD
  UserGoal["User goal / unresolved problem"]
  DesignTool["design tool
clarify scope, critique graph, produce questions"] QuestionTool["question tool
turn uncertainty into research questions"] ResearchTool["research tool
collect sources, evidence, candidates"] PlannerTool["planner tool
manage problem DAG and options"] GovernanceTool["governance tool
validate contracts and legal transitions"] Executor["executor / implementation orchestrator
materialize attempts and run ERA loop"] ProblemNode["problem_node
manageable project problem
not executable"] ResearchQuestion["research_question_packet
what must be answered"] Evidence["evidence_refs / research packets
sources and support"] NodeOption["node_option[]
possible approaches
not executable"] SelectedOption["selected node_option
chosen approach"] ExecutionUnit["execution_unit
first buildable work contract"] CandidatePatchManifest["candidate_patch_manifest
artifact-backed patch candidate set"] CandidatePatch["candidate_patch[]
patch_ref + metadata + candidate blockers"] ImplementationAttempt["implementation_attempt[]
patch-bearing candidate implementation"] AttemptEvaluation["attempt_evaluation[]
tool/evidence-backed attempt result"] AttemptSelection["attempt_selection
deterministic winner selection"] SolutionArtifact["solution_artifact
selected attempt + completion evidence"] AppliedSolution["applied_solution
isolated apply + post-apply validation"] Feedback["feedback / follow-up refs
new problems, risks, or next nodes"] UserGoal --> DesignTool DesignTool --> ProblemNode ProblemNode --> QuestionTool QuestionTool --> ResearchQuestion ResearchQuestion --> ResearchTool ResearchTool --> Evidence Evidence --> PlannerTool PlannerTool --> NodeOption NodeOption --> SelectedOption SelectedOption --> GovernanceTool GovernanceTool --> ExecutionUnit CandidateDagManifest["candidate_dag_manifest
competing graph plans"] CandidateDagSelection["candidate_dag_selection
selected graph + rejected refs"] DagExecutionUnitManifest["dag_execution_unit_manifest
selected DAG materialized into units"] PlannerTool --> CandidateDagManifest CandidateDagManifest --> CandidateDagSelection CandidateDagSelection --> DagExecutionUnitManifest DagExecutionUnitManifest --> ExecutionUnit ExecutionUnit --> Executor Executor --> CandidatePatchManifest CandidatePatchManifest --> CandidatePatch CandidatePatch --> ImplementationAttempt ImplementationAttempt --> AttemptEvaluation AttemptEvaluation --> AttemptSelection AttemptSelection --> SolutionArtifact SolutionArtifact --> AppliedSolution AppliedSolution --> Feedback Feedback --> ProblemNode GovernanceTool -. "contract checks" .-> ProblemNode GovernanceTool -. "readiness gates" .-> NodeOption GovernanceTool -. "execution-unit legality" .-> ExecutionUnit GovernanceTool -. "attempt/evaluation/selection contracts" .-> AttemptEvaluation GovernanceTool -. "apply policy" .-> AppliedSolution

Current Boundary

What works now

The repo can rank and apply supplied patch candidates in an isolated target. The next major boundary is autonomous candidate generation that emits the same candidate_patch_manifest contract.