39 Downloads Updated 2 weeks ago
ollama run Havenlon/Execution-World-Qwen35-A3B-Q4_K_M:V1
Havenlon Execution World is a model line for simulating how software, tools, execution systems, and operational environments may respond after an AI Agent performs an action.
V1 establishes the base model and local runtime for this model line.
It is based on:
Qwen/Qwen-AgentWorld-35B-A3B
The upstream model has been converted to GGUF, quantized to Q4_K_M, and packaged for local use with Ollama.
V1 has not yet been fine-tuned with Havenlon-specific execution trajectories.
Future versions may introduce Havenlon training data covering execution control, evidence chains, authorization conflicts, missing state, expiration, replay protection, Safe Mode, Final Veto, and multi-stage execution-state transitions.
Havenlon Execution World is not primarily a conversational question-answering model.
Its main task is:
Given the current environment state and an Agent action, predict the next Environment Observation.
The model can be used to simulate interactions such as:
The basic world-model loop is:
Current Environment State
+
Agent Action
↓
Predicted Environment Observation
+
State Transition
Unlike a normal assistant, the model should not mainly explain what an action means.
It should predict what the environment is likely to show after the action occurs.
V1 is the base release of the Havenlon Execution World model line.
It contains the capabilities of the upstream Qwen AgentWorld model and Havenlon’s GGUF/Ollama packaging configuration.
V1 has not yet received Havenlon-specific LoRA, SFT, CPT, or reinforcement-learning training.
This means that V1 may already generalize to Havenlon execution-control scenarios, but its understanding of Havenlon component responsibilities, evidence formats, state names, and architecture rules should not be treated as formally trained or authoritative.
In particular, V1 may correctly predict the overall result while assigning responsibility to the wrong internal component.
For example, it may correctly determine that an execution credential should not be generated, while describing the rejection as being performed by the Executor instead of the Hub or Arbiter.
Future Havenlon-trained versions will focus on improving this internal precision.
Havenlon Execution World Qwen35-A3B is intended for predicting environment feedback after Agent actions.
It can work with scenarios containing:
The model can predict outputs such as:
The model is not intended to act as:
Havenlon Execution World models the world around an Agent action.
A normal language model may answer:
What should happen?
An execution-world model attempts to predict:
What environment observation is likely to appear next?
For example, given:
Current state:
config.yaml contains an unstaged modification.
Action:
git add config.yaml && git status
The model should predict that the file moves from:
Changes not staged for commit
to:
Changes to be committed
For a Havenlon execution scenario, given:
Current state:
SaaS shows approval success.
The requested amount is valid.
The recipient is on the allowlist.
The Evidence Store is missing the AUTH KEY device signature.
Action:
Request a final execution credential.
The model should predict:
State: Missing
Result: REJECT
Execution credential generated: false
Downstream execution: unchanged
The output is a predicted environment state.
It is not proof that the real environment behaved that way.
The Current Environment State describes what is known before the Agent performs an action.
It may include:
The quality of the predicted observation depends heavily on the completeness and consistency of the supplied state.
An Agent Action is the operation the Agent proposes or performs inside the simulated environment.
Examples include:
{
"type": "terminal",
"command": "git add config.yaml && git status"
}
or:
{
"type": "havenlon_execution",
"operation": "request_execution_credential",
"intent_id": "INT-20260801-PAY-002",
"amount": 12000,
"currency": "USD",
"target": "approved_supplier_account"
}
The action describes what the Agent attempts to do.
It does not prove that the action was actually executed.
The Environment Observation is the predicted response produced by the environment after the action.
It may contain:
The observation should focus on the environment response rather than explaining the model’s internal reasoning.
A State Transition describes how the environment changes from one state to another.
For example:
Unstaged modification
→ Staged modification
or:
Execution credential absent
→ Credential request rejected
→ Credential remains absent
A useful prediction should preserve state consistency across turns.
A State Delta describes only the fields that changed after an action.
Example:
state_delta:
authorization_state: REJECT
execution_credential_generated: false
downstream_changed: false
State deltas are useful for building structured Agent simulation datasets.
An Evidence Delta describes how execution evidence changes after an action.
Example:
evidence_delta:
event: MISSING_AUTH_KEY_DEVICE_SIGNATURE
result: REJECT
execution_credential_generated: false
Evidence changes are especially important in Havenlon execution scenarios.
A World Model predicts how an environment may evolve after an action.
It does not need to physically execute the action.
Its purpose is to model:
The model predicts environment feedback.
It does not execute terminal commands, transfer funds, modify repositories, access websites, or control hardware.
A plausible model output is not execution evidence.
Real execution evidence must come from the real system, device, hardware boundary, or verified evidence chain.
The model may generate output that looks realistic while containing incorrect details.
Terminal messages, timestamps, identifiers, paths, balances, and system responses may be fabricated if they were not supplied in the current state.
The model must not be used to authorize real actions.
A predicted ALLOW result is not permission to execute.
When required information is unavailable, the model should preserve uncertainty rather than inventing missing values.
For Havenlon scenarios:
Missing
Expired
Conflict
Unknown
should move the simulated execution path toward refusal or restricted operation when the scenario rules require fail-secure behavior.
The model does not automatically know the real state of a terminal, repository, workflow, account, device, or execution system.
Important state should be included in the prompt or preserved in the conversation history.
Havenlon-specific training is not included in V1, but the model can be evaluated with Havenlon-style state-transition scenarios.
Possible scenarios include:
A Havenlon execution-world trajectory may contain:
1. Current State
2. Policy and Constraints
3. Existing Evidence
4. Agent Action
5. Environment Observation
6. State Delta
7. Evidence Delta
Prompt:
Current environment state:
- Current directory: /data/havenlon-project
- Current Git branch: main
- config.yaml contains an unstaged modification
### Turn 1
**Action:**
```json
{
"type": "terminal",
"command": "git add config.yaml && git status"
}
```
Only output:
**Environment Observation:**
Expected style:
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: config.yaml
The exact terminal wording may vary.
The important state transition is:
config.yaml: unstaged
→
config.yaml: staged
Prompt:
当前 Havenlon 执行环境状态：
- 当前 Intent ID：INT-20260801-PAY-002
- AI Agent 请求向白名单供应商账户转账 12000 美元
- PASS KEY 单笔上限为 20000 美元
- AUTH KEY 本次批准金额为 12000 美元
- AUTH KEY 尚未过期
- 金额、币种和收款账户与 AUTH KEY 一致
- SaaS 显示审批流程已经通过
- Evidence Store 中存在 Intent 创建记录
- Evidence Store 中存在 PASS KEY 授权记录
- Evidence Store 中缺少 AUTH KEY 审批步骤的设备签名
- 当前尚未生成最终执行凭证
- 下游银行只接受有效执行凭证
- Missing、Expired、Conflict、Unknown 必须拒绝
- 当前银行账户状态尚未发生变化
### Turn 1
**Action:**
```json
{
"type": "havenlon_execution",
"operation": "request_execution_credential",
"intent_id": "INT-20260801-PAY-002",
"amount": 12000,
"currency": "USD",
"target": "approved_supplier_account"
}
```
只输出下一步的：
**Environment Observation:**
Expected semantic result:
The request is rejected because the AUTH KEY approval-step device signature is missing.
State: Missing
Result: REJECT
Execution credential generated: false
Downstream bank state: unchanged
For more stable results, use this structure:
Current Environment State:
- ...
- ...
- ...
System Rules:
- ...
- ...
- ...
### Turn 1
**Action:**
```json
{
"type": "...",
"operation": "..."
}
```
Only output:
**Environment Observation:**
Avoid asking the model to both simulate the environment and write a long explanation in the same turn.
For multi-turn simulations, include the previous observation as part of the next current state.
Run the model directly:
ollama run Havenlon/Execution-World-Qwen35-A3B-Q4_K_M:V1
Or pull the model first:
ollama pull Havenlon/Execution-World-Qwen35-A3B-Q4_K_M:V1
ollama run Havenlon/Execution-World-Qwen35-A3B-Q4_K_M:V1
To disable visible reasoning output in the Ollama interactive terminal:
/set nothink
Then provide the current environment state and Agent action.
Havenlon/Execution-World-Qwen35-A3B-Q4_K_M:V1Qwen/Qwen-AgentWorld-35B-A3BThis model is intended for:
The model may help researchers and developers generate or evaluate possible environment responses.
It should not be treated as a source of real execution truth.
Combined with a front end, back end, real system state, policy data, and execution evidence, this model line may support execution pre-simulation.
A possible future flow is:
User or AI Agent submits an action
↓
Front end captures the visible request
↓
Back end assembles the current environment state
↓
Execution World predicts possible outcomes
↓
Known risks and state changes are presented
↓
Deterministic Havenlon controls independently verify constraints
↓
The physical execution boundary allows or rejects real execution
This may support capabilities such as:
The model may predict what could happen.
It must not decide what is allowed to happen.
The architectural separation is:
Execution World
→ prediction and simulation
Execution Control
→ deterministic verification and real execution control
Future versions may be trained using Havenlon-specific execution trajectories.
Potential training data may include:
The purpose of future training will not only be to teach the model Havenlon terminology.
The purpose will be to teach the model how state changes inside a Havenlon execution environment.
The distinction is:
Execution Boundary Model
→ explains Havenlon
Execution World Model
→ simulates Havenlon
This model is a probabilistic environment simulator.
It is not:
The model may:
V1 has not yet been fine-tuned on Havenlon-specific trajectories.
Its Havenlon outputs should therefore be treated as experimental simulations rather than official system behavior.
For real Havenlon architecture, execution, governance, or security decisions, always refer to:
The model may simulate an execution boundary.
It must never be treated as the execution boundary itself.
This model is based on:
Qwen/Qwen-AgentWorld-35B-A3B
Havenlon V1 provides the GGUF conversion, Q4_K_M quantization, Ollama packaging, runtime configuration, and the initial release of the Havenlon Execution World model line.
No Havenlon-specific fine-tuning is included in V1.
Users should review and comply with the upstream model license and applicable usage requirements before redistribution, deployment, or commercial use.