ENTRY I / PROJECT

Entry I is trying to answer a simple question.

What should happen when software keeps acting after the situation behind an earlier decision has changed?

Still being builtOnly selected work is publicBased in New Zealand

THE PROJECT

Turning the question into work people can inspect.

Entry I is a New Zealand research and development project. The work is still being built, tested and refined.

The questionStill being investigated

The workBeing built and tested

Finished productNot yet

Real-world deploymentNot claimed

Customers / market proofNot claimed

Protected workKept private

PART OF A WIDER FIELD

The question is not mine alone. The work still has to earn its place.

Identity, authorization, monitoring, policy enforcement, revocation, audit and other controls already exist across security and systems work.

Entry I does not claim those areas are new. Public differentiation has to come from what is actually built, tested, checked and supported by evidence.

HOW TO READ ENTRY I

Question first. Claims later.

Ask the question

Start with a real situation where the basis for an earlier decision has changed.

Build something testable

Turn the question into software and scenarios that can be examined.

Try to break assumptions

Use tests, corrections and review to see what survives.

Publish only what the evidence supports

Keep claims smaller than the evidence, not larger.

BUILT BY

Eric Churches · New Zealand

Entry I began as a question about what should happen when software keeps acting after the circumstances behind an earlier decision have changed.

The aim is to build and test that question rather than treat the idea itself as proof.

See the build →Read the research →Try an example →

See the wider context, public work and ways to get involved

PART OF A WIDER FIELD

The question is not mine alone. The work still has to earn its place.

Related questions already exist across security, authorization and agent research. Entry I does not claim the broad problem as uniquely its own.

The differentiation has to come from implementation, testing, correction and evidence.

Question→Define it→Build it→Try to break it→Check the evidence→Real deployment · not claimed

Public record

Want to see the public work?

Research

Start with the question in plain English.

Read the research note → Open → 02

Signals

See outside developments that are worth watching.

See the Signals → Open → 03

Build

See selected progress and corrections that can be shared publicly.

See the Build Log → Open →

TALK TO ME

See something worth challenging or helping with?

I’m open to useful conversations with researchers, reviewers, specialists, programmes and people who may be able to support the work.

Getting in touch starts a conversation. Nothing more is assumed.

Work with Entry I → Email Eric →

WHAT STAYS PRIVATE

Some of the work is not public.

Protected implementation details, security-sensitive material and unpublished solution work stay private.