Check intent against reality.
Compare requirements, product logic and implementation to validate what was actually built.
Verifying here means putting something somebody wrote next to the product that already exists. You paste a brief, a specification or a change request, and GitMir splits it into three lists: what the product recognises, what it cannot tell apart and needs a person to settle, and what it has never heard of. Finished work gets the same treatment — what a task promised to change, set against what the product actually started doing.
Open the Documents tab of a project and paste the document — a brief, a spec, an email.
Press Compare and read the three lists: recognised, ambiguous, never heard of.
For an ambiguous phrase, pick which part of the product it means; the answer is kept with your name, so nobody is asked again.
Open the Work tab to read what each closed task promised against what actually changed.
The comparison is against the model built from your code, not against a running system or a test suite — GitMir runs nothing to check it. It counts reach only for phrases that landed; anything still unresolved is deliberately left out rather than guessed at. Nothing you paste is stored — only the word answers you confirm. And the check for whether an action is allowed from the state a record is in exists only as an MCP tool: there is no screen for it in the workspace yet.
See it on a real product.
Three models are published in full and open without an account. Ask one of them the question this page is about.