MarcelRoozekrans/Minos.NET is an unofficial C# client for Jev-style decision endpoints. Its useful contribution is client engineering: typed questions, explicit protocol handling, provider configuration, and application-owned decisions about when to allow, review, or block.

I inspected the README, question generator, System One client/settings, request writer, response reader, and guardrail sample at revision cee27cf2bee21ce2d3cf59ddd399791e6bd52fea. I did not build or run it: this host has no dotnet executable. No live Jev result, allocation measurement, or Native AOT claim was reproduced; this is not a security audit.

Generate the plumbing, not the judgment

  • C# attributes declare yes/no-like questions, choices, and scores; a source generator emits the question-set implementation at compile time.
  • The System One writer sends actual state, model, and questions fields—not a chat prompt masquerading as a decision API.
  • The response reader rejects missing, null, or duplicate answers; optional model and usage metadata are read more leniently.
  • Provider-neutral application interfaces separate the caller from the System One protocol adapter.

Keep policy in ordinary code

The guardrail sample screens each message once, then applies strict and lenient policies to the same answer. Different thresholds are application choices, not different model judgments.

  • Each hazard has a review threshold and an optional block threshold.
  • Professional-advice requests go to review on topic alone; the severity rule can escalate that review.
  • Transport failure throws rather than becoming an “allow” verdict.
  • The sample explicitly calls its thresholds starting points to tune on your own traffic.

Provider switches need more than matching JSON

Custom and local-server settings do not automatically inherit hosted-provider keys from the environment. The client also exposes retry, logging, and tracing stages. These are inspectable implementation choices—not proof of safe deployment or interchangeable model behavior.

The README describes an early-development project not yet published to NuGet, despite showing package-install commands. Its offline samples and gated live-smoke tests are useful scaffolding, but their existence is not a passing test result from this inspection.

Typed output is not a correct decision. The README’s “calibrated” wording does not establish that confidence matches real error rates on your workload. Native AOT means compiling to a native executable ahead of time; the project’s compatibility and allocation claims still need an actual build and measurements. Start with labeled cases, inspect false approvals, and validate the policy independently of the client.