Evidyne Integration (SPI)
Contract
Every operation returns the §32 response contract:
{
"status": "PASS|REPAIR|REGENERATE|REPLAN|REJECT|UNRESOLVED|BLOCKED",
"project_id": "...",
"state_version": 18,
"artifacts": ["A_JOB_SHOT_0001"],
"evidence": [],
"warnings": [],
"next_actions": ["render_master"]
}
Failures add failure_type, location, repair_plan.
Operations (Phase 1 implemented)
| Operation | Purpose | Notes |
|---|---|---|
create_project(prompt) |
new ProjectState | returns project_id |
interpret_project(pid) |
IntentEngine + idea generation | separates must: constraints |
generate_ideas(pid, task) |
adaptive idea budget | normal=3 / important=5 / major=8 |
commit_concept(pid, idea_id) |
governing rules | |
compile_production(pid) |
plan → DAG; validates | BLOCKED on cycles/invalid jobs |
render_draft(pid) |
scheduler + renderer | cached artifacts |
evaluate_draft(pid) |
level-1 checks → fusion → arbiter | evidence attached |
get_project_state(pid, fields?) |
lazy field retrieval (§68) | |
get_evidence(pid) / get_job_status(pid) |
observation |
Evidyne loop
THINK interpret_project / generate_ideas / commit_concept
EXECUTE compile_production / render_draft
VERIFY evaluate_draft (status REPAIR -> repair_plan in response)
REPAIR (Phase 7; today evaluate_draft reports repair targets)
Evidyne only needs project_id + these JSON calls; renderer and model internals stay behind
ModelRouter. In Phase 1 Evidyne can run the whole mock loop without any GPU.
Adding a renderer (§43-J)
Implement the Renderer protocol (spi/renderers/base.py): name, kind, capabilities(),
generate(request) -> {"artifact": uri, ...}. Register with ModelRouter.register(kind, renderer).
Phase 2 ships WanRenderer (diffusers WanPipeline) behind this exact interface.