Looking for builders working on production AI reliability / governance problems

Thanks — I went through the developer preview repo and tried the Naina sample.

Happy to review from a production AI reliability / runtime governance angle, but to give you feedback that's actually useful (rather than reactions to the README), I'd need a bit more of the contract surface. The preview shows the shape of a governed response but not the semantics behind the fields, and that's where the interesting reliability questions live. A few specifics:

1. Traceability — what's in a trace_id beyond the ID itself? Is there a span model (request → policy eval → model call → post-filter), and is it exportable in OpenTelemetry GenAI conventions, or proprietary? For production review, the schema and retention story matter more than the field name.

2. Policy / escalation — "policy_applied: true" is a boolean in the sample. What's the policy authoring model (rules, code, DSL), how are conflicts resolved, and what does the escalation state machine look like when a policy blocks, soft-blocks, or routes to a human? Is there a deterministic fallback contract when the engine itself is unavailable, or does the calling app degrade open?

3. Memory boundaries — "memory_scope: session" implies a boundary, but the interesting questions are: where is session memory stored, how is cross-session leakage prevented at the model layer (not just the API layer), and how does scope interact with tool calls and retrieval?

4. Workflow control — does "mode" compose (multiple policies stacked), or is it a single enum? How do you handle mid-conversation mode transitions and the audit trail for them?

5. Runtime governance — what are the failure modes you've already mapped? Latency budget under policy eval, behavior when the upstream provider returns a refusal vs. a policy-violating completion, replay/determinism guarantees for audit.

If you can share the API reference doc, the policy/mode spec, and an example trace payload (even redacted), I can give you concrete feedback on each of those — and flag where I think the framing would or wouldn't hold up against NIST AI RMF and the OTel GenAI semconv work that enterprise buyers are starting to ask about.

On where I could contribute: most useful for me would be review of the trace schema and escalation contract, and pressure-testing the failure-mode story. Let me know what you can share and we can go from there.

That makes sense, especially if NEES is meant to carry the philosophy of the system itself.

I agree that for infrastructure, trust has to come from architecture, reliability, developer experience, and real production behavior first. A polished name alone does not create that.

The only distinction I’d keep pressure-testing is internal clarity vs external recall.

“NEES Core Engine” may be clear to people who already understand the governance model, but the harder question is whether a new buyer or developer remembers it as a serious production control layer after one exposure.

If the product stays close to the framework/community layer, the current name can work.

If it becomes a broader enterprise governance platform, that is where the naming ceiling may matter more.