mzero

Adaptive decisions over event sequences

mzero combines a trained neural decision model with an application-scoped learning runtime. It turns evidence and earlier decisions into typed judgments, connects those judgments to learned behavior patterns, and carries the decision history forward as new events arrive.

The neural core is a fine-tuned Qwen3.5-2B text backbone distributed as a merged Q4_K_M GGUF. The accompanying reference runtime supplies the event graph, decision lineage, adaptive question selection, persistent relation memory, feedback, and notification delivery.

An application defines what it wants to assess. mzero follows the event sequence, asks the relevant questions, maintains competing interpretations, and learns from independently confirmed outcomes.

Release at a glance

Property	Value
Model name	mzero
Release	0.1.0
Base model	Qwen/Qwen3.5-2B
Base revision	15852e8c16360a2fea060d615a32b45270f8a8fc
Text backbone parameters	1,881,825,088
Adaptation	Rank-4 LoRA on the final two full-attention blocks
Merged adapter tensors	28
Neural training updates	191
Synthetic training episodes	64
Distribution	GGUF, Q4_K_M, approximately 1.27 GB
Input	Text and JSON evidence
Output	A selected typed answer and option-level scores
Reference runtime	Python 3.11+, llama.cpp, SQLite, Docker
License	Apache 2.0

The trained adapter is already merged into the GGUF. Downloading a separate adapter or base checkpoint is not part of the inference startup.

The architecture

Application events
       |
       v
Immutable event ledger ------ caused_by / supersedes links
       |
       v
Evidence selection + observed state + earlier decision references
       |
       +---------------------------+
       |                           |
       v                           v
mzero GGUF                   Typed fact reader
semantic judgments           explicit source values
       |                           |
       +-------------+-------------+
                     v
            Adaptive question sequence
                     |
                     v
           Learned question-pattern relationships
                     |
                     v
          Versioned decision + evidence references
                     |
                     v
          Persistent notification outbox
                     |
                     v
                Webhook / SNS

Independently confirmed outcomes --> relation memory + feedback records
Confirmed semantic targets -------> neural training samples

1. The neural decision core

mzero evaluates a bounded question using the provided state, the ordered history of earlier answers, and a described answer set. The runtime associates answer names with single-token letter labels, verifies the actual token boundary, and normalizes scores over the allowed options.

The PyTorch training path reads selected logits at one answer position. The GGUF inference path returns one constrained label token together with option scores. Thinking is disabled for this decision protocol; a long generated explanation is not part of the API response.

The model supports described choice sets, yes/no judgments, and ordered score levels through the reference schema. Sequence packs use four explicit answer states:

Answer	Meaning
yes	Evidence supports the condition.
no	Evidence supports its opposite.
unknown	More evidence is needed to resolve the condition.
irrelevant	The condition does not apply to this context.

Option scores express the model's relative preference among the answers supplied with that question. Final pattern compatibility is a separate quantity computed by relation memory.

2. The event graph

Events are immutable records identified within a namespace and stream. Each event carries its occurrence time, observed fields, and optional causal or correction links.

• caused_by connects a result to the events that led to it.
• supersedes introduces a correction while retaining the earlier record.
• The ingestion runtime records when evidence became available.
• A decision uses evidence available at its cutoff.

The runtime groups connected event chains and asks the neural model about their relevance to the pack's goal. Explicit entity and field bindings also provide an observed state with source event IDs. This lets applications combine natural-language interpretation with direct access to structured observations.

3. Decision inheritance

Every decision is a persisted node with its own ID, parent ID, selected event IDs, question sequence, answer scores, and memory revision. A new decision can inherit the preceding node in its stream or explicitly fork from a selected parent.

Earlier answers travel as provisional judgments with source references. The observed event ledger remains the source of facts. Correction links and question fingerprints identify when an inherited judgment belongs to an earlier observation or question definition.

This creates a traceable chain of reasoning across time: applications can inspect what was observed, what was asked, what changed, and which decision preceded the current one.

4. Adaptive relation memory

Relation memory learns associations between questions and confirmed outcome patterns. A confirmed pattern might be routine, planned_change, anomaly, or an application-defined label.

For each pattern and question, the runtime maintains a signed observation total and a support accumulator. The relationship weight is their ratio. Compatibility with a new episode is the average agreement between its available observations and the pattern's learned relationships.

When feedback updates a pattern, its earlier accumulators are multiplied by a retention factor before new observations are added. This gives recent confirmed evidence greater influence within that pattern. The sequence runtime uses a retention factor of 0.8.

The next question is selected from the remaining question catalog by comparing the relationships of the leading candidate patterns. A bounded exploration step also visits questions whose coverage is still developing.

Memory is scoped by namespace + pack. Evidence and decision lineage are scoped by namespace + stream. This allows different applications to use the same neural core while maintaining their own learned behavior.

How the structure grows

mzero's organization has three connected layers:

1. Observed event graph: new events add causal edges and correction edges.
2. Decision lineage: each new assessment adds a decision node linked to its predecessor.
3. Learned relation structure: confirmed outcomes add or update pattern-question relationships and recorded pattern transitions.

Organic growth comes from new evidence and confirmed feedback:

• A newly confirmed outcome label introduces a pattern to the local relation memory.
• Repeated confirmations strengthen its observed question relationships.
• Changed outcomes adjust the relationships associated with that pattern.
• Confirmed parent-to-child decisions contribute to the transition history.
• Applications extend the question catalog by publishing a new pack version.
• A changed question meaning receives a new fingerprint, preserving the interpretation of existing decisions.

The learned structure is a weighted set of relationships with an evolving question sequence. It does not require the application author to prewrite every branch or final outcome path.

Two learning timescales

Immediate adaptation: confirmed feedback updates the application's persistent relation memory. Subsequent decisions use the updated relationships.

Neural release evolution: confirmed semantic targets are retained as training samples. A new neural checkpoint can be trained, evaluated, merged, and exported as a versioned GGUF. The GGUF file represents a particular release; adaptive application memory is stored in the runtime database.

What makes the approach different?

The table compares common implementation patterns at the architecture level.

Dimension	Static decision tree	Independent LLM classification	mzero reference architecture
Organization	Authored branch paths	One prompt and response per request	Event graph, decision lineage, and learned relationships
Earlier evidence	Carried through explicit branches	Included by the calling application	Selected from a persistent event ledger with source references
Next question	Fixed by the tree	Defined by each prompt	Selected using learned relationships and bounded exploration
Changing behavior	Branch definitions are edited	Prompt or weights are updated	Confirmed outcomes update application-scoped memory
Output	Branch result	Parsed model response	Typed judgments, pattern compatibility, and a decision record
Corrections	Application-specific handling	New prompt context	Explicit supersedes links and preserved decision history
Deployment artifact	Rule definitions	Model and prompting code	Merged GGUF plus a persistent reference runtime

The neural layer supplies semantic judgments. Typed bindings preserve direct access to explicit source values. Relation memory connects observations to application-defined patterns. These components can be combined according to the task.

A fully synthetic example

Consider a fictional service that authorizes an operation and then records its completion:

{
  "namespace": "demo-app",
  "stream": "synthetic-operation-001",
  "pack": "authorization-audit",
  "id": "authorization-event",
  "occurred_at": 1700000000,
  "data": {
    "operation": "synthetic-operation-001",
    "authorization": "denied",
    "completed": false
  }
}

The next event references the first:

{
  "namespace": "demo-app",
  "stream": "synthetic-operation-001",
  "pack": "authorization-audit",
  "id": "completion-event",
  "occurred_at": 1700000001,
  "caused_by": ["authorization-event"],
  "data": {
    "operation": "synthetic-operation-001",
    "completed": true
  }
}

The example pack reads explicit authorization and completion fields through typed bindings. mzero evaluates causal relevance, and relation memory compares the resulting observations with previously confirmed patterns such as permitted, blocked, and anomaly.

An anomaly decision creates a durable notification carrying the decision ID, parent ID, source event IDs, judgments, pattern, and memory revision. A configured webhook or SNS topic receives the notification. A separate synthetic audit result then confirms the outcome and teaches the local memory.

All names, IDs, times, operations, and outcomes in the published examples are fictional. The downloadable runtime starts with a fresh database; no learned customer state is bundled.

Synthetic verification included with this release

Check	Recorded result	What was exercised
GGUF decision checks	32 correct judgments out of 32	Fresh synthetic episodes from the training generator family, with ordered answer inheritance
Event-to-alert example	3 correct pattern decisions out of 3 new operations after 3 teaching cases	GGUF relevance, typed observations, learned relation memory, and HTTP integration
Notification delivery	1 received notification	The synthetic anomaly was delivered to a local webhook receiver
Persistence and replay	Passed	Restart preserved memory and delivery state; the same event returned the same job

The counts describe these specific synthetic checks. The published synthetic-validation.json contains a curated summary and synthetic case labels, with no raw service traces or local runtime identifiers.

Download and run

The repository includes the merged GGUF, its hash manifest, an English architecture guide, synthetic verification metadata, and a reference runtime archive.

python3 -m pip install -U huggingface_hub
hf download denizumutdereli/mzero --local-dir mzero
cd mzero
python3 -m zipfile -e mzero-runtime.zip .
export MZERO_API_TOKEN="$(openssl rand -hex 32)"
docker compose up --build -d
curl http://127.0.0.1:8765/health

The CPU Docker image builds a pinned llama.cpp server and runs the authenticated API. The model is included in the image, and /data is a persistent Docker volume. No Hugging Face token is used for inference after the files are downloaded.

To run the synthetic event-to-alert example with a local receiver:

export MZERO_WEBHOOK_URL=http://host.docker.internal:9090/alerts
docker compose up -d
python3 examples/event_to_alert.py --output demo-results.json

The example registers the packs, teaches three synthetic patterns through confirmed feedback, and evaluates three new synthetic operations. The event API responds with a persisted job ID; decisions are processed asynchronously.

For a direct neural judgment through a separately running llama.cpp server, use examples/score_decision.py. The bundled llama-grammar-probs.patch applies grammar before probability sampling so the returned option scores correspond to the allowed labels. Prompt version 2 and thinking-disabled formatting are used throughout.

PYTHONPATH=src python3 examples/score_decision.py --llama-url http://127.0.0.1:8081

See ARCHITECTURE.md for API routes, pack configuration, feedback records, deployment composition, and runtime details.

Application areas

The same core can be connected to different event schemas and question packs:

• Service workflows: authorization, completion, retries, and recovery sequences.
• User sessions: changes in interaction patterns and independently confirmed intent.
• Equipment telemetry: observed state changes, operating sequences, and maintenance outcomes.
• Agent workflows: ordered tool results, evidence checks, and verified task outcomes.

Applications supply their goal, observations, questions, and confirmed pattern labels. The runtime owns the common event, inheritance, learning, and delivery machinery.

Training and artifact provenance

The active adapter was trained on 64 synthetic behavioral episodes using 191 decision-position updates. Supervision was applied to selected answer logits. Outcome targets were kept outside inference evidence and question history.

Rank-4 adapters target the attention and MLP projections in full-attention blocks 19 and 23, with LoRA alpha 8. The 28 adapter tensors were merged into the text backbone before conversion and quantization.

The release manifest records the public base model revision, adapter hash, GGUF hash, quantization, prompt version, parameter count, and pinned llama.cpp revision. Training and published examples use synthetic observations generated for this project.

GGUF SHA-256: 6b27d05d5eb839cdf65d276bf146eace8fcbdc10489439acad1fbc66904524fa

The repository publishes model and reference-runtime artifacts. Credentials, local environment files, runtime databases, application event logs, private repository information, and the original research attachments are excluded from the publication.