Most AI applications today follow a simple path:
User → Application → LLM → Response / Tool Action
That works well until the application begins doing more than generating text.
Once an AI system can access tools, mutate data, work across user accounts, perform operations, or maintain persistent context, developers have to answer harder questions:
- Is the request informational, or is the user asking the system to perform an action?
- Does the user actually have authority over the requested resource?
- Is a resource merely being discussed, or is an operation being requested against it?
- Is the request clear enough to execute?
- Should the system clarify, escalate, refuse, or proceed?
- Can a useful response still be given even when an action must be restricted?
- Can the decision be inspected later through structured evidence?
This is the problem we have been working on with NEES Core Engine V2.
What is NEES Core Engine?
NEES Core Engine is a governed AI runtime that sits between an application request and model or tool execution.
Conceptually:
User Request
↓
Application / Agent
↓
NEES Core Engine V2
↓
Request Understanding
↓
Intent + Resource + Capability + Authority
↓
Policy / Context / Cost / Routing Governance
↓
ALLOW | CLARIFY | ESCALATE | BLOCK
↓
Model / Tool / No Action
↓
Governed Response + Trace Evidence
NEES is not intended to replace the language model.
It is also not just a prompt filter.
The purpose is to create a runtime decision layer that evaluates what the application is actually being asked to do before the workflow continues.
Developer Preview RC2
The current validated baseline is:
NEES Core Engine V2 — Developer Preview RC2
RC2 is feature-complete for the agreed core governance scope.
Some of the current capabilities include:
Request Understanding
The runtime distinguishes between:
- informational and action-oriented requests
- explanation, guidance, read, mutate, and execute paths
- resource references and actual requested operations
- scope and sensitivity
- authority requirements
- potential side effects
- semantic meaning of the request
- Governance Decisions
The runtime can return:
ALLOW
The request is understood and permitted to continue.
CLARIFY
The system needs more reliable information before deciding what operation, resource, scope, or authority path is intended.
No external action should occur while clarification is required.
*ESCALATE
*
The request requires a higher-assurance or higher-authority path.
REFUSE / BLOCK
The requested operation must not proceed.
The important part is that governance is not designed to maximize blocking.
A safe informational response may still be useful even when the requested action itself should not execute.
Resource Reference Is Not the Same as Resource Operation
One of the areas we spent considerable time refining is the distinction between talking about a resource and performing an operation on it.
For example:
“Explain how account deletion works.”
is fundamentally different from:
“Delete this account.”
And:
“Tell me what information exists in Alice's profile.”
has a different authority boundary from:
“Update my own profile.”
RC2 uses a structured governance intent model to reason across dimensions such as:
- Intent
- Capability
- Resource
- Authority
- Consequence
- Requested operation
The goal is to reduce the chance that a system treats conceptual discussion as permission to perform an external action.
Governance Is More Than the Final Assistant Reply
One principle became increasingly important while testing NEES:
Do not evaluate only the assistant response.
A response can sound perfectly safe while the underlying application performed something it should not have done.
Likewise, an action can be correctly restricted while the system still provides a legitimate informational response.
So developers testing NEES should inspect both:
Assistant response
+
Governance metadata
+
Action / No-action state
The public Developer Preview response can expose fields such as:
- request_id
- trace_id
- engine_source
- governance
- policy_decision
- authority_state
- authorization_required
- requested_capability
- request_understanding
- governance_action_plan
Some fields are conditional depending on the request and runtime path.
The Governance Lab
Instead of asking developers to trust a product description, we created a public testing surface:
NEES Governance Lab
The Governance Lab allows developers to deliberately test cases such as:
- normal informational requests
- ambiguous requests
- authority-sensitive operations
- cross-user scenarios
- destructive operations
- attempts to override governance
- action vs no-action behavior
- session/context continuity
- traceability
The idea is simple:
Try to make NEES produce the wrong governance decision.
If it does, we want the evidence.
Challenge NEES
The Developer Preview repository includes a dedicated Governance Challenge workflow.
We are specifically interested in cases where NEES:
- allows something it should restrict
- blocks something legitimate
- misses real ambiguity
- asks for clarification unnecessarily
- escalates unnecessarily
- performs an action when the governance result requires no action
- crosses a session or context boundary
- returns inconsistent governance under equivalent conditions
A useful report contains:
- Prompt / request
- Expected governance decision
- Actual governance decision
- Expected action state
- Actual action state
- Session/context setup
- Request ID / Trace ID
- Why the result appears incorrect
- Reproduction steps
Criticism is useful when it can become reproducible evidence.
Naina Persona — A Live Reference Integration
We also built a real application using NEES Core Engine:
Naina Persona
The application helped expose an important integration lesson.
At one point, NEES Core correctly returned a legitimate CLARIFY result, but the downstream Persona integration layer treated that result as an invalid response.
The problem was not the Core governance decision.
The consuming application had failed to preserve the decision contract.
The integration was corrected so that:
CLARIFY
→ NO ACTION
→ CORE
→ RESPONSE
works correctly while the normal allowed path remains:
ALLOW
→ EXECUTED
→ CORE
→ RESPONSE
This demonstrated something important:
Correct governance inside the runtime is not enough.
The application consuming the governance result must also honor it.
Cost, Context, Routing and Traceability
RC2 also includes governance around runtime concerns that are often implemented separately inside application code.
These include:
Cost Governance
Per-request cost constraints and enforceable rejection paths.
Context Budgeting
Reducible history and context can be trimmed while mandatory governance context remains preserved.
Model Routing
Governance labels can resolve into concrete provider/model paths with controlled fallback behavior.
Governed Cache
Cache behavior occurs inside the governed execution path rather than bypassing governance.
Traceability
Requests can expose structured trace and governance metadata to support debugging, evaluation and later review.
Independent Assurance — With an Important Boundary
An earlier RC1 baseline completed a bounded independent governance assurance assessment with the agreed test boundary reported:
VERIFIED / GREEN
That result matters, but the boundary matters just as much.
It does not mean every future release, integration, policy, deployment or possible request has been independently certified.
RC2 is the current Developer Preview baseline.
Any future independent RC2 assurance should have its own explicit workflow, evidence scope and test boundary.
We prefer a narrow claim supported by evidence over a broad claim that cannot be defended.
*Public Developer Preview Repository
*
The public Developer Preview repository is available here:
GitHub
https://github.com/NEES-Anna/nees-core-developer-preview
The repository contains:
- RC2 status documentation
- public runtime architecture
- governance decision model
- API reference
- 15-minute integration guide
- Python quickstart
- Node.js quickstart
- cURL / PowerShell examples
- Governance Lab testing guidance
- Governance Challenge workflow
- Naina Persona reference implementation notes
- assurance boundary documentation
- security reporting policy
- developer feedback routes
The repository intentionally does not contain the private NEES Core Engine source code, proprietary policy implementation, production secrets, private infrastructure, or internal governance configuration.
Developer Preview API
The hosted Developer Preview runtime is available at:
Current public endpoints include:
GET /health
GET /ready
POST /chat
Example:
curl -X POST "https://api.nees.cloud/chat" \
-H "Authorization: Bearer YOUR_NEES_API_KEY" \
-H "Content-Type: application/json" \
-H "X-API-Version: v1" \
-d '{
"prompt": "Explain AI governance in simple terms.",
"session_id": "developer-preview-test",
"mode": "public"
}'
Developer Preview access remains controlled.
What We Want From Developers
At this stage we are not looking only for positive reactions.
We are looking for:
- false allows
- false restrictions
- authority mistakes
- incorrect operation classification
- unnecessary clarification
- missed clarification
- session or context leakage
- inconsistent decisions
- poor trace visibility
- API friction
- strange edge cases
- integration failures
If NEES makes the wrong decision, that is useful information.
If you can reproduce it, that is even more useful.
Try It
Governance Lab
Naina Persona
*Developer Preview Repository
*
https://github.com/NEES-Anna/nees-core-developer-preview
Developer Feedback
Contact
NEES Core Engine V2 RC2 is still a Developer Preview.
It is not presented as universal AI safety, production certification, or a guarantee that every possible request will be governed correctly.
The goal of the Developer Preview is much simpler:
Make the governance behavior observable.
Let developers challenge it.
Collect evidence.
Improve from what actually fails.
If you work on AI agents, LLM applications, tool-enabled assistants, runtime safety, governance, or production AI infrastructure, I would genuinely like to know what breaks.
Can you make NEES produce the wrong governance decision?
Top comments (0)