What the project is now, where it is meant to go, and what a satisfactory next state looks like.
A control layer for projects that evolve with AI
AI changes your project.
Keep its direction in view.
Keep the goal, conditions and evidence in view while agents change your code. EolSpace tracks what changed, what still holds, and what needs your decision — version by version.
01
Capture state and direction
What is true now, where the project should go, and what must not be lost on the way.
02
Observe changes against it
Code, configuration, agent instructions, checks, and other supported signals around the project.
03
Surface what actually changed
Expected progress, an unwanted deviation, or a condition that can no longer be established from the available evidence.
Pre-release. Independent project. Built in Ukraine.
What EolSpace keeps track of.
Your goal, the agents changing the code, and the evidence they leave behind — connected in one versioned view.
Behaviors, access rules, constraints, and other conditions that must remain true while the project evolves.
What changed as expected, what changed unexpectedly, and what can no longer be established from current evidence.
Supported instruction files, hooks, editor autorun, MCP enablement, permissions, and related agent-facing configuration.
Checks, manifests, receipts, provenance, previous results, and whether older evidence still applies to the current version.
Mutation checks, falsifiers, scoped claims, and explicit uncertainty instead of a generic pass/fail.
Specified invisible Unicode, non-printable terminal output, and other supported operational or profile-specific probes.
Pause on a broken or unresolved condition, refine the route, and continue without silently weakening what counts as acceptable.
TUI
Project state, without leaving the terminal.
Project, active certificate, conditions and run history in one place. See why a conclusion no longer applies, what the loop did, and whether a decision is needed from you.
- 01Version A
Previous conclusion
- 02A → B
Version changes
- 03not-established
Old evidence no longer applies
- 04Re-check B
Next action appears
Current conclusion
See the project’s current holds, broken, or not-established state.
Validity after change
A version change makes stale conclusions visible instead of silently carrying them forward.
Conditions in context
See which conditions apply to the current subject and what still needs to be checked.
What needs you
The interface separates executor activity from the decisions that require the owner.
AWAY FROM THE TERMINAL
Keep the project in view from your phone.
A compact view for time away from the terminal: the latest state, the change that needs attention, and a clear next step.
Pre-release phone concept · planned surface
Illustrative sequence: a checked version changes, an alert appears, and the next action is a re-check. Notifications and phone actions are not yet released.
Current state
See the latest project conclusion and which conditions are still valid.
Alerts
A visible signal for broken conditions, missing evidence, or a required re-check.
Change review
See what changed as expected, what changed unexpectedly, and what remains unresolved.
Attention needed
The exact item that needs review or an owner decision, with its reason.
History
Follow recent state transitions and the project’s short decision trail.
Next action
See whether the next step is re-check, review, handoff, or route refinement.
Every important condition has an explicit state.
It holds, it is broken, or it is not-established because the available evidence is insufficient or no longer applies to the current version. Unknown is not treated as success.
holds
The checked condition is satisfied for this version.
subject: project@current-versionYour goal. Your conditions. A versioned contract.
The Adaptive Certificate is a versioned work contract: the goal, conditions, verification methods, thresholds and adaptation budget. A new result creates a new justified state; it does not rewrite the old one.
01
Direction
Where the project is meant to go and what a satisfactory result looks like.
02
Current conditions
What is already true and must not quietly disappear while the project evolves.
03
Evidence
How each important condition is checked, what was observed, and which version the result belongs to.
04
Adaptation
The route may be refined, but weakening an acceptance condition remains a human decision.
Version Aholdschecked here
→
Version Bnot-establishedawaits re-check
Each project version has its own state and evidence.
A previous result remains part of the history, but it does not automatically establish the same claim about a changed project. EolSpace keeps that boundary visible.
JEV / judge within the certificate
Not everything can be checked with a normal test.
JEV judges conditions within the Adaptive Certificate when a deterministic check is missing or incomplete. Its question, threshold and model version are controlled.
- 01
Deterministic check
Establishes the conditions it can verify directly.
- 02
JEV judgment
Evaluates a controlled question where that check is missing or incomplete.
- 03
EolSpace state
Agreement can support a condition when its thresholds are met. Uncertainty stays visible.
If the evidence disagrees? not-established
Pause. Investigate.
Neither side automatically wins. The condition becomes not-established until the disagreement is resolved.
Built. Being refined. Not yet publicly released.
The project has a pre-release implementation, code, and scoped verification reports. A documented real run already exercised expiry, adaptation, and reissue while leaving open conditions visible.