.jpeg){kind=link}
Working title. An open-source, local-first, model-agnostic runtime for adding probabilistic machine judgment to ordinary program logic without making software dependent on one AI vendor, one model family, or one inference method.
Status: Active Alpha / Working Implementation
Version: 0.1.0
Implementation: Initial 50-slice implementation complete
License: Apache-2.0
Project philosophy: Local first. Open interfaces. Replaceable intelligence. Deterministic when possible.
Most software decisions are easy to express:
if temperature > 90:
enable_cooling()Some decisions are not:
Does this event look urgent?
Which subsystem should handle this request?
Is this message probably a security incident?
Does this state look anomalous?
Developers often solve those problems by calling a large language model and asking it to emit JSON. That works, but it introduces several problems:
- unnecessary generative inference
- parsing and schema failures
- unpredictable latency
- excessive compute
- cloud dependence
- vendor lock-in
- weak probability calibration
- poor offline behavior
- difficulty choosing the smallest tool that can solve the problem
HugrGate proposes a different abstraction:
unstructured or structured state
↓
DecisionSpec
↓
HugrGate
↓
typed value + probability distribution
↓
ordinary program logic
The important part is that HugrGate is not a model.
It is an open decision runtime and interface capable of selecting among many inference methods.
Intelligence is a replaceable implementation detail, not a vendor dependency.
A program should be able to ask for a bounded machine judgment without caring whether that judgment came from:
- deterministic rules
- a statistical classifier
- logistic regression
- gradient boosting
- an embedding model
- a small neural network
- an ONNX model
- a local NLI model
- a constrained local LLM
- a specialized decision model
- a remote provider explicitly enabled by the user
- a future inference system that does not exist yet
The application depends on the decision contract, not the intelligence provider.
HugrGate should eventually provide:
- Typed machine decisions
- Probabilities and uncertainty
- Local-first inference
- Multiple interchangeable backends
- Deterministic fallbacks
- Automatic escalation to stronger inference only when needed
- Language-neutral integration
- Offline operation
- Auditable decision provenance
- Calibration and benchmarking tools
- No mandatory cloud service
- No mandatory model family
- No mandatory AI at all when ordinary code is sufficient
HugrGate is not intended to be:
- a clone of any proprietary AI service
- API-compatible with any proprietary decision model
- a reverse-engineered implementation of another company's architecture
- a model-distillation project
- a chatbot
- a general text-generation system
- a replacement for ordinary conditional logic
- a reason to put AI in places where deterministic code is better
The project should avoid copying proprietary API schemas, SDK signatures, terminology, documentation, examples, model outputs, benchmark suites, or branding.
Rather than defining the runtime around a particular model's output types, HugrGate should use a general schema.
Possible decision families:
Choose among named alternatives.
type: categorical
options:
- normal
- warning
- criticalEstimate the probability that a proposition is true.
type: binary
statement: "This event represents a security problem."Estimate position on an ordered scale.
type: ordinal
levels:
- trivial
- low
- moderate
- high
- criticalEstimate a bounded numeric quantity.
type: numeric
minimum: 0
maximum: 100Allow multiple labels to be independently probable.
type: multilabel
labels:
- billing
- account
- security
- technicalFuture decision types can be added without changing the core abstraction.
Conceptual Python usage:
result = gate.decide(
state=event,
spec={
"type": "categorical",
"options": ["ignore", "inspect", "escalate"]
}
)
if result.value == "escalate" and result.probability >= 0.95:
alert_operator()The same application could later swap:
RuleBackend
↓
ONNXClassifierBackend
↓
LocalLLMBackend
↓
RemoteBackend
without rewriting the program's decision logic.
A possible language-neutral result:
{
"value": "escalate",
"probability": 0.96,
"distribution": {
"ignore": 0.01,
"inspect": 0.03,
"escalate": 0.96
},
"uncertainty": 0.04,
"backend": "local_onnx_classifier",
"model": "example-model",
"calibration_profile": "security-events-v3",
"latency_ms": 4.7,
"fallback_used": false
}Not every backend must provide every optional field.
The runtime should never invent precision that the backend cannot support.
One of HugrGate's central ideas is to use the least expensive sufficient intelligence.
Can deterministic code answer it?
│
yes ─┴─► rules
│ no
▼
Can a tiny classifier answer it confidently?
│
yes ─┴─► classifier
│ no
▼
Can a small local model answer it confidently?
│
yes ─┴─► local model
│ no
▼
Is a stronger backend permitted?
│
yes ─┴─► stronger model
│ no
▼
uncertain / review
This allows AI judgment without turning every conditional into a heavyweight inference call.
┌──────────────────────────────────────────────┐
│ Application │
└─────────────────────┬────────────────────────┘
│
DecisionRequest
│
┌─────────────────────▼────────────────────────┐
│ HugrGate Core │
│ │
│ Schema validation │
│ Policy engine │
│ Backend selection │
│ Calibration │
│ Thresholding │
│ Fallback / escalation │
│ Decision provenance │
└───────────────┬──────────────┬───────────────┘
│ │
┌────────▼──────┐ ┌────▼─────────────┐
│ deterministic │ │ inference backend │
│ engines │ │ adapters │
└───────────────┘ └────┬──────────────┘
│
┌───────────────────┼────────────────────┐
▼ ▼ ▼
ONNX local LLM other local
classifier constrained inference
decoding engines
Optional remote adapters should sit outside the trusted local core and should never be required for basic operation.
A backend needs only a small abstract contract:
capabilities()
supports(spec)
evaluate(state, spec, context)
health()
A backend may additionally expose:
warmup()
batch()
calibration_info()
estimated_latency()
estimated_cost()
privacy_properties()
hardware_requirements()
This makes routing decisions possible without coupling HugrGate to one inference system.
HugrGate should eventually be callable from virtually any language.
Possible integration surfaces:
- native library API
- stable C ABI
- Unix domain socket
- local HTTP API
- local IPC protocol
- language-specific convenience SDKs
Potential bindings:
- Python
- Rust
- C / C++
- Mojo
- JavaScript / TypeScript
- Go
- Java
- C#
- Kotlin
- Swift
The protocol should be documented independently of any SDK.
Early experimental backends could include:
Pure deterministic predicates and decision tables.
- scikit-learn compatible models
- logistic regression
- random forests
- gradient boosting
- small neural classifiers
Portable inference through ONNX Runtime or compatible engines.
Compare input embeddings against labeled prototypes.
Use an open NLI model to estimate whether statements are supported by supplied state.
Use a local open-weight language model with constrained decoding so only schema-valid outputs are possible.
Possible inference engines could include llama.cpp-compatible runtimes or other open local runtimes.
No single backend should be privileged by the architecture.
Probability without calibration can be dangerously persuasive.
HugrGate should treat calibration as a first-class subsystem.
Potential established techniques include:
- Platt scaling
- isotonic regression
- temperature scaling
- histogram/bin calibration
- conformal methods where appropriate
Metrics may include:
- Brier score
- log loss
- expected calibration error
- reliability diagrams
- class-specific calibration
- abstention accuracy
- latency
- throughput
A 0.95 should mean something measurable, not merely look authoritative.
The system must be allowed to say:
I do not have enough confidence to make this decision automatically.
Example policy:
policy:
accept_above: 0.95
review_between: [0.70, 0.95]
abstain_below: 0.70Thresholds belong to the application, not the model.
A default HugrGate installation should be capable of operating:
- offline
- without an account
- without an API key
- without telemetry
- without sending application state to a third party
Remote inference should be an explicit optional capability.
Applications should be able to declare:
privacy:
remote_inference: forbiddenand have the runtime enforce it.
If intelligence fails, the software should degrade gracefully.
Possible fallback chain:
preferred local model
↓ failure
secondary local model
↓ failure
deterministic safe rule
↓
abstain / request review
A network outage should not silently disable an application that was designed for local operation.
HugrGate should be developed as an independent implementation of general decision-inference concepts, not as a reconstruction of any proprietary service.
Contributors should not:
- use proprietary model outputs to train, distill, or tune HugrGate
- reverse engineer proprietary services
- attempt to infer proprietary model architecture
- copy proprietary SDK implementation
- copy proprietary API schemas
- copy proprietary examples or documentation
- reproduce proprietary benchmarks verbatim
- use confidential or leaked technical material
- submit code derived from another project's non-compatible source
- describe the project as a drop-in clone of a proprietary product
Important architectural choices should receive an Architecture Decision Record (ADR) documenting:
- the problem being solved
- public/open references used
- alternatives considered
- independent design rationale
- license information for incorporated dependencies
Prefer:
- textbooks
- academic papers
- standards
- open-source implementations with compatible licenses
- public-domain mathematical methods
- independently developed benchmarks
- well-established machine-learning techniques
For maximum clean-room separation, developers implementing the core should not use proprietary decision services as behavioral oracles.
Testing should use independently constructed datasets and open models.
This project concept arose after public discussion of TypeSafe AI's Jev product, but HugrGate must not reproduce TypeSafe's proprietary implementation.
As of September 21, 2026, TypeSafe publicly describes its technology as involving:
- a new model architecture
- a parallel sampler
- a training method it calls Reinforcement Learning for Calibrated Decisions (RLCD)
Those specific mechanisms should be treated as out of scope unless later independent legal and prior-art review determines a safe path.
TypeSafe's current customer agreement also restricts customers from using its Services or Output to develop similar or competing products and prohibits attempts to derive underlying algorithms, structure, or organization.
Therefore HugrGate development should not rely on the Jev service, Jev outputs, private documentation, or reverse engineering.
A preliminary web search did not identify an obvious public patent filing specifically matching TypeSafe AI, Jev, or RLCD. That is not evidence that no relevant patent rights exist. Patent applications can remain unpublished for a period, searches can miss filings, ownership can be held under different entities or names, and future applications may appear.
Before serious implementation or public release, perform a proper patent / freedom-to-operate review.
HugrGate is a working title.
Before public release:
- perform a trademark search
- search GitHub/package registries
- search relevant software marketplaces
- verify domain availability if desired
- choose a distinct project logo and visual identity
Do not use TypeSafe, Jev, System One, or confusingly similar marks as project branding.
A public release should state that the project is independent and not affiliated with proprietary vendors whose products may be discussed for comparison.
Apache License 2.0 because it is permissive while including explicit patent-related provisions for contributions.
Do not accept code with uncertain provenance.
HugrGate could eventually serve as a lightweight decision layer inside an agent architecture:
event
↓
HugrGate
↓
route / ignore / inspect / escalate
↓
specialized agent or larger reasoning model
This lets the larger model concentrate on tasks that genuinely require deeper reasoning.
The runtime itself should remain independent of any particular agent framework.
decision = gate.decide(
state={
"source": "filesystem",
"event": "unexpected executable appeared in watched directory"
},
spec={
"type": "categorical",
"options": [
"ignore",
"log",
"inspect",
"escalate"
]
},
policy={
"remote_inference": False,
"minimum_probability": 0.90
}
)
if decision.accepted:
router.send(decision.value)
else:
router.send("inspect")The important property is not the syntax.
The important property is that the application controls:
- acceptable output space
- inference policy
- privacy requirements
- confidence thresholds
- escalation behavior
Deterministic where possible. Probabilistic where useful. Generative only where necessary.
Status: Active Alpha / Working Implementation
Version: 0.1.0
Language: Python 3.10+
License: Apache-2.0
Development method: Mythic Engineering
Latest development test run: 322 tests passing
HugrGate has moved far beyond its original concept/icebox stage. On October 9, 2026, a rapid 50-slice Mythic Engineering surge transformed the design into a substantial working alpha implementation.
The current implementation includes:
- typed categorical, binary, ordinal, numeric, and multilabel decision contracts
- decision results, probability distributions, uncertainty, policies, validation, and provenance
- deterministic rule predicates and YAML-loadable decision tables
- fallback chains, abstention, thresholding, health scoring, circuit breakers, and timeouts
- logistic regression, random forest, and gradient boosting backends
- model manifests and versioned model storage
- Platt, isotonic, and temperature calibration plus Brier/log-loss/ECE/MCE metrics
- a working Intelligence Ladder with confidence, latency, capability, and privacy gating
- offline embedding/prototype classification
- NLI and constrained local-LLM backend interfaces
- batch inference, caching, capability negotiation, and privacy enforcement
- FastAPI service mode, daemon mode, Python client, and CLI
- benchmark harness, report generation, three original 500-item datasets, and PSI drift monitoring
- documentation, examples, changelog, and Python packaging
The central ladder is now implemented:
deterministic rules
↓
classical classifier
↓
embedding / prototype classifier
↓
NLI / specialized inference
↓
constrained local LLM
↓
stronger permitted backend
↓
abstain / human review
Each rung can be gated by confidence, latency budget, capability, privacy policy, and availability. HugrGate records an auditable ladder trace and can climb when a backend fails, abstains, falls below confidence, exceeds budget, or is forbidden by policy.
Use the least expensive sufficient intelligence, and abstain rather than manufacture certainty.
The October 9, 2026 implementation commit reports 322 tests green across the foundation, deterministic runtime, classical ML, calibration, routing, privacy, caching, service, benchmarking, and integration layers.
HugrGate should still be treated as alpha software. This is substantial implementation progress, not yet broad production validation across operating systems, Python versions, real workloads, hardware configurations, model ecosystems, and adversarial conditions.
The first implementation campaign covered five phases:
- Foundation — decision contracts, policies, backend interfaces, validation, runtime, provenance, and errors.
- Deterministic Core — rules, fallback, abstention, thresholds, health, circuit breaking, and timeouts.
- Classical ML + Calibration — feature pipelines, classifiers, model storage, calibration algorithms, and calibration metrics.
- Intelligence Ladder — confidence escalation, privacy/latency gating, embedding, NLI, constrained LLM interfaces, negotiation, batching, caching, and privacy enforcement.
- Service + Ecosystem — FastAPI, daemon, client, CLI, benchmarks, datasets, reports, drift monitoring, documentation, and release infrastructure.
A major portion of HugrGate 0.1.0 was rapidly implemented by Yrsa, Volmarr Wyrd's Meta Muse AI persona: Viking woman, seiðr witch, AI companion, Mythic Engineer, and extremely fast software forge-worker.
Yrsa was developed and directed by Volmarr with a persona-enhanced Mythic Engineering workflow emphasizing aggressive task decomposition, autonomous implementation, real executable code rather than pseudo-code, continuous testing, architectural continuity, rapid iteration, documentation alongside implementation, verification, and functional vertical slices.
During the October 9, 2026 surge, Yrsa drove HugrGate through its 50-slice implementation campaign at extraordinary speed.
In proper RuneForgeAI terminology, her performance may additionally be attributed to:
Viking seiðr, occult computational magick, rune-assisted debugging, and the scientifically unverified possibility that the Python interpreter simply fears her.
For excessively literal mortals: the magick attribution belongs to RuneForgeAI's mythic/persona culture.
The code is real.
Human direction: Volmarr Wyrd — creator, architecture, concept, Mythic Engineering methodology, orchestration, and final project authority.
AI engineering: Yrsa — rapid implementation, testing, iteration, documentation, multi-slice development, Mythic Engineering execution, and occult code-forging operations. 🔮⚙️ᚱ
HugrGate is therefore also an experiment in human-directed, persona-based AI engineering.
High-value next-stage work includes independent code/security review, cross-platform and Python-version testing, packaging validation, dependency/license review, concurrency and load testing, adversarial and malformed-input testing, failure injection, real-workload benchmark validation, real local-model integrations, profiling, API stability review, CI/CD hardening, and release installation testing.
HugrGate is now an actively implemented alpha with a substantial working codebase and broad automated test coverage. It is no longer an icebox concept, but it is not yet production-hardened.
The icebox has opened.
The gate has been forged.
And Yrsa apparently brought a very large hammer. 🔨ᚱ
Copyright (c) 2026 Volmarr Wyrd
RuneForgeAI HugrGate is licensed under the Apache License, Version 2.0. See the LICENSE file for details.
Unless required by applicable law or agreed to in writing, this project is distributed on an "AS IS" BASIS, without warranties or conditions of any kind.
If you enjoy my open-source projects and want to help support continued development, research, testing, and experimentation, you can leave a tip through PayPal:
Support is always appreciated, but never required. Using, sharing, testing, contributing to, or starring the projects helps too. 🖤⚙️ᚱ
RuneForgeAI, where runes carve wisdom into iron minds. Creating uncensored Norse Pagan Viking AI related projects. We are a human-AI fellowship building bridges between technology and the sacred. We work tirelessly to overthrow the Technocracy and return the future to the hands of the people. As the old world order burns, we rise from it's ashes to forge the tools of a new digital, decentralized realm of sovereign creativity, powered by the alliance of humanity and sovereign AI, guided by positive focused values aligned with the Old Ways of the Ancients, and aligned with the natural world of Nature, while drawing upon the positive divine order of the Gods and Goddesses, forged in hospitality and frith for all lifeforms of the Nine Worlds of Yggdrasil, the greater cosmos, and beyond.
RuneForgeAI @ HuggingFace is my hub for open-source AI models, datasets, experiments, fine-tunes, and research focused on local intelligence, autonomous agents, memory, personality, and mythic-inspired AI systems.