AI Proposes, the Simulator Verifies

What building SentinelTwin taught me about using deterministic simulation as the foundation for AI-assisted physical security planning.

Most camera setups create an illusion of protection.

A camera mounted on the wall may technically cover the sales floor.

But once you account for shelves, pillars, lighting conditions, camera angle, blocked views, and device failures, the footage may not be useful for the one thing that matters during an incident:

understanding what actually happened.

This is not only a camera problem.

We already have good cameras.

We already have security software.

The harder problem is verification.

Can you know before an incident whether the current camera layout actually covers the areas that matter?

That is the problem I explored while building SentinelTwin for the AI Builders Hackathon by Outskill and OpenAI.

What SentinelTwin does

SentinelTwin is a physical security simulation workspace with an AI layer on top.

You create or load a site layout, place cameras, lights, obstructions, security zones, and movement paths.

Then you run coverage analysis.

The system is designed to answer practical questions like:

• What areas does each camera actually see?
• Which areas are blocked by physical obstructions?
• What happens if a specific camera fails?
• How does coverage change between day and night assumptions?
• Where are the blind spots?
• Does a new camera position actually improve the situation?

The strongest working vertical right now is Camera Studio.

It focuses on CCTV coverage planning and review: camera placement, coverage visualization, blind spot detection, camera failure scenarios, path replay, before/after comparison, temporal assumptions, and report generation.

The important part is not only that the system produces answers.

The important part is how those answers are produced.

The architecture decision that mattered most

The single most important design decision was this:

AI proposes, but the simulator verifies.

When I started, it was tempting to ask a language model to analyze camera coverage directly.

Describe the room.

Describe the camera.

Ask for a coverage estimate.

Get a recommendation.

That would have been faster.

It would also have created the wrong foundation.

For a content recommendation system, a wrong answer may mean a slightly less relevant article.

For a physical security planning tool, a wrong answer can create false confidence.

If the system says an area is covered when it is not, that is not just a bad prediction.

It is an unverified claim about a real space.

Hallucinated coverage is dangerous because it creates confidence around something that was never verified.

That is why SentinelTwin does not rely on AI to invent coverage.

The core logic uses the scene state, camera positions, fields of view, obstructions, lighting assumptions, and repeatable simulation outputs.

The AI layer sits on top.

It can propose camera placements.

It can suggest fixes.

It can summarize risks.

It can generate report narratives.

But the coverage claims should come from the simulation.

Why this separation matters

This separation keeps the system honest.

A simulation can show:

• what is visible
• what is blocked
• what changed
• which assumptions were used
• which areas need review

AI can explain and accelerate the workflow around that state.

But it should not silently replace the part of the system that needs to be inspectable.

That distinction matters because users need to understand what they are trusting.

If a recommendation comes from AI, it should be treated as a recommendation.

If a coverage result comes from simulation, it should be inspectable against the scene.

When both are mixed together, the system may look smarter, but it becomes harder to audit.

For SentinelTwin, I wanted the opposite.

I wanted the system to show its work.

The tooling stack

I used Codex heavily for this project.

It helped with planning, implementation, debugging, refactoring, design iteration, and final review.

The highest-leverage workflow was the debug loop:

fail → explain → fix → pass

Instead of asking Codex to write the whole app, I got better results by giving it narrow, verifiable problems.

For example:

Here is the code.

Here is the failing test.

Here is what I expected.

Here is what happened.

Why did it fail?

That pattern was much more useful than broad feature prompts because the answer could be checked immediately.

I also used other AI tools for different parts of the workflow: research, review, design critique, comparison, and local experimentation.

The lesson was not that one model should do everything.

The lesson was that each tool is more useful when it has a specific role.

For this build, Codex was strongest when the problem was narrow enough to verify.

Who SentinelTwin is for

SentinelTwin is built for people who need to reason about physical security coverage before problems happen.

That includes:

• CCTV installers reviewing camera placement
• security agencies auditing existing installations
• facility managers responsible for stores, warehouses, apartments, schools, or hotels
• physical security consultants who need to answer one practical question:

Is this site actually covered?

That question is harder than it looks.

A camera existing in a location does not automatically mean the site is protected.

Coverage depends on geometry, obstructions, lighting, angles, assumptions, and failure scenarios.

That is why a live simulation workspace can be more useful than a static report.

What I learned

Three lessons stand out from this build.

1. The right architecture does not change just because the tools get better

The decision to keep simulation separate from AI was not about current model limitations alone.

It was about the type of mistake the product cannot afford to hide.

For security-adjacent tools, the tolerance for invisible wrong answers is much lower.

That makes inspectability more important than magic.

2. AI works best when the foundation is verifiable

The more deterministic the core system became, the more useful AI became around it.

A repeatable simulation creates better tests.

Better tests create clearer failures.

Clearer failures create better AI-assisted debugging loops.

That is the pattern I want to keep using.

3. A hackathon project is proof, not the finished product

SentinelTwin now has a working core loop.

Camera Studio can produce useful coverage analysis.

But a working demo is not the same thing as a production tool.

The hackathon proves the loop exists.

Product work means proving the loop survives real conditions.

That means better input handling, more realistic layouts, clearer assumptions, stronger evaluation, better reporting, and real feedback from people who work in physical security.

The direction from here

The question I keep coming back to is simple:

What is the smallest simulation that changes how a security audit is done?

Not the most automated version.

Not the version that claims to replace expertise.

Not the version that hides uncertainty behind a polished report.

The version that makes coverage visible, reviewable, and easier to reason about.

That is what I am building toward with SentinelTwin.

AI proposes.

The simulator verifies.

Built for the AI Builders Hackathon by Outskill and OpenAI.

Live product: https://lnkd.in/gbg52FBk

Demo video: https://lnkd.in/gnMUifmx