PostIdea's verification engine checks whether your implementation matches the spec you built it against. Not whether it "looks right." Whether the identifiers the spec requires are actually present in your code.
This is deterministic verification. No LLM guessing. No subjective code review. Three layers of checks that either pass or fail based on what's in your source code.
The architecture engine generates a list of expected paths based on your architecture decisions. Layer 1 checks whether those paths exist in your file tree.
Example: If your architecture chose PostgreSQL + REST API, Layer 1 expects api/, models/, and migrations/ directories. If any are missing, Layer 1 fails.
Why this matters: Missing directories mean missing infrastructure. If migrations/ is absent, your database schema has no version control. That's a deployment risk.
Every functional requirement in your spec has testable signals — specific identifiers (class names, function names) that must appear in your source code. Layer 2 searches for these identifiers as word-boundary matches in your stripped source (comments, strings, and docstrings removed).
Example: If FR-01 requires MessageService and send_message, Layer 2 searches your source for both. If either is missing, FR-01 fails.
Why this matters: Missing identifiers mean missing features. If send_message is absent, the requirement isn't implemented. That's a spec violation.
Layer 3 is an LLM-based semantic review of your code diff against the spec. It checks for out-of-scope features, missing error handling, and implementation gaps that Layers 1 and 2 can't catch.
Important: Layer 3 is advisory only. It never affects the pass/fail verdict. Only Layers 1 and 2 gate the result.
Why this matters: Layer 3 catches edge cases and provides context, but it doesn't override deterministic checks. A verification engine that relies on LLM judgment is not a verification engine.
| Problem | Layer | Example |
|---|---|---|
| Missing infrastructure | Layer 1 | migrations/ directory absent |
| Missing features | Layer 2 | ReviewService not found in source |
| Out-of-scope features | Layer 3 | Microservices added when spec asked for monolith |
| Missing error handling | Layer 3 | No 404 handling on GET /api/products/{id} |
E-commerce marketplace — 5/6 requirements passed:
One missing feature (review system) caught before shipping. The spec required ReviewService and create_review. Neither was found in the implementation. Layer 2 failed. The gap was fixed before launch.
Real-time chat application — 0/6 requirements passed:
Six missing features caught before shipping. No WebSocket handler, no room service, no presence tracking, no notification system, no message history, no search. Layer 1 and Layer 2 both failed. The implementation was a REST API, not a real-time chat application.
Start building a verifiable spec →
A verification engine that passes everything is not a verification engine. PostIdea's verification is deterministic: if the identifiers the spec requires are not in your source code, the verdict is FAILED.
No subjective judgment. No "looks good to me." Either the code matches the spec or it doesn't.
That's the only way to verify code matches specification.
Check your architecture risk score — free, no signup →
Build a verifiable spec →
See a real verification example →