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 rules-based verification. Three layers of checks that either pass or fail based on what's in your source code. Layers 1 and 2 are deterministic; Layer 3 is LLM-based advisory only.
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.
Check your architecture risk score →
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.
Check your architecture risk score →
Start building a verifiable spec →
Check your architecture risk score →
A verification engine that passes everything is not a verification engine. PostIdea's verification uses deterministic checks for Layers 1 and 2: if the identifiers the spec requires are not in your source code, the verdict is FAILED.
No subjective judgment for the pass/fail verdict. No "looks good to me." Either the code matches the spec or it doesn't. Layer 3 provides advisory context but never overrides the deterministic verdict.
That's the only way to verify code matches specification. Related examples: e-commerce marketplace verification or real-time chat application verification.
Check your architecture risk score →