Explicit job contract
Objectives, constraints, required evidence, allowed tools, action boundaries, and completion checks remain visible throughout the run. A repair attempt works against the same contract instead of inventing an easier target.
CR Lite Syndicate
Govern the work, not just the prompt.
CR Lite executes governed work, evaluates it against explicit checks, and reports the result with evidence and an honest delivery standing. It can improve a result without hiding what remains unverified, blocked, or failed. The operator chooses the objective, constraints, checks, and action boundaries; the runtime keeps those decisions attached to the work as it moves through the circuit.
The model produces. Independent deterministic checks evaluate. CR Lite repairs, records standing, and returns the strongest candidate.
illustrative receipt
$ cr-lite run "review release notes"
checksexplicit
evidenceattached
{
"standing": "verified",
"stanceReview": "supported"
}This is one illustrative verified case. It is not a promise that every run verifies or produces a deliverable.
What CR Lite builds
A work circuit shaped around the objective.
CR Lite turns the job into a bounded circuit: roles, inputs, tools, checks, repair limits, evidence, and action gates. The circuit can be small for one answer or coordinated across specialist blocks when the work requires different kinds of judgment.
Independent evaluation
Deterministic checks and gathered evidence evaluate the work. Requirements, schemas, tests, source support, and tool results can each contribute evidence. A model opinion cannot overwrite a failed authoritative check.
Bounded repair
Failures return specific guidance to the producing block while preserving the failing evidence. Attempt, cost, and time limits stop the circuit from repairing forever or hiding an unresolved problem behind repeated generation.
Governed actions
Reading and analysis can proceed under the approved policy. Saving, exporting, committing, deploying, spending, sending, or changing a connected system can require explicit approval and a recorded action result.
Execution and checking
One loop with four understandable stages.
Every stage has a defined responsibility. Producing, checking, repairing, and reporting remain separate so the final receipt can show what happened and what still needs judgment.
- 01
Tell CR Lite what needs to be done
Give it an objective, relevant context, constraints, and the checks that should govern the result. Define required evidence, acceptable tools, action limits, and the conditions for completion. The job remains explicit instead of drifting with the conversation or quietly changing during repair.
- 02
Build and run the work circuit
CR Lite selects the blocks, tools, skills, and scoped memory needed for the job, then records how they fit together. Read-only work can proceed while consequential actions remain gated. The circuit preserves handoffs and intermediate evidence so a later reviewer can understand how the candidate was produced.
- 03
Evaluate and repair
Independent deterministic checks evaluate requirements, structure, code, sources, secrets, and tool results. Failed checks become targeted repair guidance instead of being replaced by a favorable model opinion. Repair remains bounded by attempt, cost, and action limits, and unresolved failures remain visible in the receipt.
- 04
Return evidence and standing
The run returns the strongest candidate it found, supporting evidence, unresolved issues, and an honest delivery standing. When no viable deliverable exists, blocked or failed can say so directly. The receipt separates what ran, what checks established, and what still requires human judgment before another action.
Delivery truth
Standing says what CR Lite can honestly deliver.
A viable strongest candidate is preserved when one exists. Verification quality is not confused with delivery, and a difficult result is not renamed to make the run look successful.
The standing answers whether CR Lite can release a candidate and under what conditions. Evidence in the same receipt explains which requirements were checked, which checks failed, and whether any output is partial, blocked, or absent.
verified | completed | best_effort | blocked | failed
Standing is release and delivery truth. stanceReview is independent source-support/conflict review, not delivery status. Deterministic failures remain authoritative.
View technical details
failed may include the strongest derived output, but it does not guarantee that an output exists. blocked can also return no deliverable.
Lowercase verified is not Certification Garage certification. Certification outcomes are job-specific and separate from CR Lite delivery standing.
A source review may report support or conflict while deterministic execution still fails. The source review cannot reverse that failure.
Workbench and workloads
Govern work across the systems it actually touches.
Inputs can be objectives, data, events, APIs, repositories, records, and connected systems. Outputs can be artifacts, decisions, transactions, system updates, reports, code, or downstream actions.
Reading client files from a folder and depositing a finished artifact is one shipped workflow example, not the product boundary. The same governance model applies when work begins or ends somewhere else.
A work circuit can begin from a human objective, repository change, scheduled event, incoming record, or connected API. What matters is that inputs, checks, decisions, and authorized actions remain explicit enough to inspect after the run.
Research and reports
Gather sources, distinguish direct evidence from inference, compare support and conflict, repair unsupported claims, and return a report with citations, unresolved questions, and evidence that another person can review.
Code and repositories
Inspect a repository, identify the affected surfaces, make scoped changes, run explicit checks, explain the diff, and preserve compiler, test, security, or policy failures instead of talking past them.
Data and records
Transform structured inputs, validate schemas, relationships, and required fields, record exceptions and rejected records, and return the strongest usable artifact with its limitations and validation evidence.
Connected operations
Coordinate approved APIs and tools, carry evidence across handoffs, pause before consequential actions, and return decisions, system updates, or downstream actions with a reviewable audit trail.
Hosted demo and local license
See the governed workflow, then run the engine where your work lives.
The hosted demo uses controlled scenarios and does not accept private repositories or arbitrary customer code. The paid local license runs CR Lite on your machine; external tools connect only under your configuration and approval.