Use Cases¶
Real-world recipes for multi-component orchestration. Each recipe starts with a GoalInput JSON spec — the canonical input schema that drives G6's goal decomposition engine. The GoalInput feeds into the GoalDecomposer, which builds a SearchTree of actionable nodes with diagnostics, guardrails, and resource tracking.
Every recipe demonstrates capabilities that go beyond what a bare LLM can do: formal proofs via propositional DPLL, counterexample-guided inductive synthesis (CEGIS), CSF hazard bounding, persistent retrieval indices, and genetic algorithm optimisation.
I want to...¶
| Goal | Recipe | Tier |
|---|---|---|
| Build a grounded research pipeline with formal verification | Research Pipeline | Basic |
| Audit code for OWASP Top 10 and prove security invariants | Code Review & Safety | Basic |
| Train ML models with genetic optimisation and formal evaluation | Data Analysis | Basic |
| Run bounded self-improvement with CEGIS and drift detection | Self-Improving Agent | Premium |
| Apply G6 to security, data science, research, architecture, or DevOps | Domain Recipes | Varies |
| Orchestrate multi-team product launches with hierarchical goal decomposition | Goal & Planning | Basic |
| Plan and simulate robotic pick-and-place pipelines | Physical AI | Premium |
| Produce podcast episodes from research notes: script, voice, music, cover art | Creative & Media | Basic |
| Build cross-modal product search across text, images, and audio | Multimodal | Premium |
| Deploy autonomous agents with escalation governance | Experience & Autonomy | Premium |
| Build adaptive tutoring systems with cognitive architecture selection | Cognitive Architectures | Premium |
| Build multi-provider agent ensembles with expert system fallback | Agents & LLM | Basic |
| Deploy domain-specific AI assistants for professional services | Job Agents | Basic |
GoalInput Schema¶
All recipes use the GoalInput Pydantic model from mvp.goal_engine.schema:
| Field | Type | Description |
|---|---|---|
goal | str | What you want G6 to accomplish |
context | str \| None | Background information, dataset details, environment |
constraints | list[str] | Hard requirements the solution must satisfy |
resource_bounds | ResourceBoundsSchema \| None | Token, time, and disk limits |
guardrails | list[GuardrailSpec] | Declarative hard constraints (halt on violation) |
checkpoints | list[CheckpointSpec] | Soft assertions (logged, don't halt) |
breakpoints | list[BreakpointSpec] | HITL pause points for human review |
subtasks | list[GoalInput] | Pre-specified decomposition (recursive) |
See examples/sample_goal.json for a complete, schema-validated example.
HITL Controls¶
G6 supports three types of declarative human-in-the-loop (HITL) controls that can be attached to any GoalInput — at the top level or per-subtask:
- Guardrails (
GuardrailSpec) — hard constraints that halt execution when violated. Use for safety-critical invariants like CSF hazard bounds or resource limits. - Checkpoints (
CheckpointSpec) — soft assertions that are evaluated and logged but do not halt the pipeline. Use for quality gates like metric thresholds. - Breakpoints (
BreakpointSpec) — pause points where the system stops and waits for human review before continuing. Use for high-stakes decisions like deployment approvals.
Each spec references a predicate from the PREDICATE_REGISTRY (e.g., resource_limit, metric_above, csf_hazard, always_pause). At runtime, GoalDecomposer resolves these specs into their executable counterparts and attaches them to the SearchTree. See examples/sample_goal.json for a complete example with all three control types, and the Safety-Guarded Goals tutorial for a walkthrough.