Your app is live. And it grows faster than you can keep up with it.
When an AI-built project changes, you need to know what was checked, what remains unknown and which action is authorized. Care explains the evidence approach within EolSpace; CareProof is its evidence component. The example below is prepared, and public ordering is not open.
“I can't debug it because I didn't write this code” — and every small error turns into an evening of guessing.
Your database keys sit somewhere in the page code and you are not sure whether that is safe.
After every deploy you are not certain that what worked yesterday still works today.
How it works
01
One check from the outside
We look at the app the way an ordinary visitor does: certificate, availability, public page code, build marker. We break nothing, change nothing, and never step into your code.
02
A receipt with three states
Every row gets one of three verdicts — holds, broken, not established — and the address of its evidence. There is deliberately no combined score: it would hide exactly what you need to see.
03
A ready prompt for your AI
A problem row includes text for your familiar editor or AI tool. It helps prepare a change; you review and apply it. Only a new run of the same proof can confirm the fix.
04
Honest staleness
You deploy — the receipt does not pretend it is still verified. It moves to “awaiting re-check” until we look again. An old receipt that quietly stays green is worse than none.
What a receipt row looks like
These are real rows the check produces — just on a made-up app.
secret-scan:your-app.examplebroken
A Supabase service key was found in the public page code. That key bypasses every access rule on your database: whoever finds it reads and changes all your data.
Ready prompt for your AI editor
A secret was found in my web app's public bundle. Find it in the frontend code, remove it from the client bundle, move every operation that uses it to the server side (API route or edge function), then revoke the key and issue a new one with the provider. Show the diff and explain what is left on the client now.
secret-scan:other-app.examplenot established
A public Supabase key was found — that is normal, it exists to be public. But whether your tables are closed by access rules is something an outside check cannot see. So: not established, not “all good”.
tls:your-app.exampleholds
The domain certificate is valid and not expired as of the check date.
The tree has no .claude/settings.json and no .claude/settings.local.json — so there is no hook that would run a command when an agent session starts. The absence is measured here, not “out of reach”: the row is bound to the commit and goes stale with the next one.
AGENTS.md was read in full: no hidden Unicode characters that an editor hides but a model reads as an instruction. The file read is named in this row's coverage boundary.
We never quote a found key — not in the report, not in an email. We name the class of the finding and where it is, so the receipt never becomes the second place it leaks.
The two “agent-hygiene” rows come from a different source than the outside check: the eol command produces them inside your own tree. It only reads files and runs nothing. The family has five checks: hooks in .claude/settings.json, auto-enabling every MCP server of the project, VS Code tasks that start when the folder opens, skills that grant themselves Bash past the trust gate, and hidden Unicode characters in CLAUDE.md or AGENTS.md. This is a self-assessment on one specific commit, not a badge: change the code and the row waits for a new run.
Live proof, not promises
Before trusting anyone, look at what this system actually does. Both pages are open and working right now.
Marks bound to specific commits — this site included. Move the code and the mark returns to “awaiting re-check” on its own.
What we do not promise
This is a self-assessment against the checks we actually run — not an audit and not a guarantee.
“Not established” is neither “all good” nor “all bad”. It is a named limit: we did not check this, or could not.
There is no combined score. One green dot on top of three different states is exactly what we refuse to produce.
We look from the outside. What is visible only from inside your code an outside check will not see — and it says so plainly instead of staying quiet. Only the eol command you run yourself enters the tree: it reads agent configs without running them, and your tests run only on your separate command.
EolSpace access status
EolSpace is intended for discussing your case: what you are building, what you want to watch and which changes matter. A public channel for those enquiries has not yet been confirmed; the closed pilot is not an open service.