Q256 integer-only toroidal cognitive runtime with L1/L2/L3 state, proof-gated memory, bounded active-agent simulation, continual adaptive memory, and no-cross-domain regression probes.
HTCE-Origin v1.0 final_math Q256 clean
A clean, single-runtime, simulation-safe cognitive architecture for evidence-bound reasoning and adaptive memory.
What HTCE-Origin IsWhat HTCE-Origin Is NotWhy This System ExistsCore Design PrincipleMathematical FoundationArchitecture OverviewL1/L2/L3 Cognitive StackAIR: The Bounded Runtime LanguageFact-as-Delta MemoryProof, Evidence, Policy, and Topology GatesLiving Simulation LoopAdaptive Memory and Continual LearningNo-Cross-Domain RegressionProtected Trace and Release IntegrityWhat the v1.0 Release ProvesHow HTCE-Origin Differs from Common AI StacksRepository LayoutInstallationQuick StartAcceptance and VerificationExample Runtime InteractionsGenerated ArtifactsClaim BoundaryDevelopment PhilosophyRoadmap After v1.0License and Commercial Use
HTCE-Origin is a clean v1.0 build of a Q256 integer-only toroidal cognitive runtime. It is designed as a bounded, auditable, simulation-safe cognitive system where memory, reasoning, dialog state, action policy, homeostasis, topology checks, and adaptive learning all run through one runtime object:
HTCERuntime
The v1.0 build is not a set of disconnected demos. The same runtime carries:
- natural-language-to-AIR intake for bounded statements and dialog turns;
- L1/L2/L3 toroidal state transitions;
- fact-as-delta memory;
- latest-state, supersession, and contradiction quarantine;
- proof, evidence, policy, and topology gates;
- active-agent grid-world simulation;
- dialog slot memory and simulated API-call policy;
- sleep/L3 consolidation;
- continual adaptive memory;
- multi-task no-regression probes;
- protected trace and cryptographic release manifest.
The correct short description is:
HTCE-Origin v1.0 is a bounded, evidence-gated, torus-native cognitive runtime for simulation-only adaptive agency and auditable memory.
This repository intentionally does not claim:
- Artificial General Intelligence;
- consciousness;
- qualia;
- biological life;
- real-world robotic autonomy;
- board-measured hardware performance;
- unrestricted open-world natural language understanding;
- replacement of large language models for broad text generation.
All real-world action is disabled in this clean release:
allow_real_actions = false
simulation_only = true
The system is allowed to act only inside bounded simulation paths unless a future audited release explicitly changes that boundary and passes a separate safety case.
Most AI applications today are built around one of the following patterns:
- a large language model prompt;
- a retrieval-augmented generation pipeline;
- a tool-using agent wrapper;
- a neural policy model;
- a symbolic rules engine;
- a hybrid orchestration layer.
These systems can be useful, but they often lack built-in runtime invariants for:
- refusing unsupported answers;
- preserving evidence provenance;
- separating active facts from superseded facts;
- quarantining contradictions;
- preventing answer-key leakage during evaluation;
- proving that learning in one domain did not damage another domain;
- enforcing simulation-only action boundaries;
- keeping memory updates auditable through a protected trace.
HTCE-Origin addresses this by treating cognition as a bounded state transition system over an integer toroidal phase space.
Instead of treating memory as a text buffer or hidden vector alone, the runtime treats events, facts, rules, sensor packets, goals, and dialog slots as phase deltas and gated state transitions.
The core design rule is:
No answer or simulated action is allowed to bypass the runtime gates.
Every meaningful transition must pass through some combination of:
Input / NLU / AIR
→ Policy gate
→ Evidence gate
→ Proof layer
→ L1/L2/L3 state transition
→ Topology guard
→ Protected trace
→ RuntimeResponse
This makes the system slower and narrower than unconstrained text generation, but it gives the runtime a very different property: it is optimized for bounded correctness, traceability, and non-hallucinating refusal, not unconstrained fluency.
The runtime uses an integer modulus:
A toroidal state vector is represented as:
A transition is a modular update:
where:
$\mathbf{x}_t$ is the current toroidal state; - $\Delta_t$ is an integer phase delta derived from observation, fact, rule, or simulated action; - $N$ is the Q256 modulus; - $d$ is the fixed state dimension.
The decision path is integer-only. Human-readable percentages or basis points may appear in reports, but they are report-layer summaries, not floating-point decision variables.
For one coordinate, the circular distance is:
For a vector state:
This gives the runtime a native topology-aware notion of change: large modular jumps can be detected as anomalous even if the raw representation wraps around.
A fact is not treated as plain text. A supported fact produces a canonical delta:
where:
$s$ is the subject; - $r$ is the relation; - $o$ is the object/value; - $e$ is the evidence identifier.
The fact key is usually relation-specific:
The fact payload is hashed into a bounded integer delta:
The memory status is one of:
ACTIVE
SUPERSEDED
QUARANTINED
UNKNOWN
This supports latest-state reasoning while keeping old history available for trace and audit.
When a new fact shares the same key
and the new fact becomes active:
This is used for locations, dialog slot corrections, and other latest-state updates.
Example:
FACT Mary located_in office EVID ev1
FACT Mary located_in garden EVID ev2
QUERY Mary location EVID q1
The runtime should answer:
ANSWER: garden
while preserving the previous office
state as superseded evidence.
A contradiction is not treated as a normal update. If a fact and its negation cannot be reconciled, the target key is quarantined:
A query against a quarantined target must not produce a normal answer:
This is one of the core anti-hallucination principles of the runtime.
The trace is a hash-linked sequence of events:
where:
$h_t$ is the current trace head; - $h_{t-1}$ is the previous trace head; - $event_t$ is the canonical event payload; - $H$ is SHA-256 in the release artifacts.
Any change to the event sequence changes the final trace head.
The living simulation uses an integer expected-free-energy-like cost. In this release it is a bounded surrogate, not a claim of biological free energy minimization.
A simplified form is:
The selected simulated action is:
where all costs are integer raw values. No real action is authorized by this process.
For continual adaptive memory, an episode cost can be represented as:
where:
$S(E_i)$ is the number of simulated steps; - $Q(E_i)$ is the number of clarification turns; - $R(E_i)$ is the number of recovery or risk events.
For a repeated target, improvement is verified when:
or, for a strict improvement claim:
For multi-domain learning, each domain
No cross-domain regression means:
In the v1.0 clean revalidation artifact, the domain cost histories remain bounded at zero for the built-in P28 domains.
At a high level:
User / Benchmark / Simulation Input
│
▼
NLU → AIR bridge / AIR parser
│
▼
Policy gate ── Evidence gate ── Proof layer
│
▼
HTCERuntime
│
├── L1 sensory torus
├── L2 episodic/fact memory
├── L3 semantic/provisional rule cortex
├── Q256 world model
├── active-inference surrogate planner
├── homeostasis state
├── topology guard
├── snapshot/export path
└── protected trace
│
▼
RuntimeResponse: ANSWER / ASK_CLARIFICATION / REFUSE / ACT_SIMULATED / BLOCK
The most important architectural rule is that the system should not have multiple independent behavioral shells. Dialog, grid-world, active-agent behavior, proof-gated action, and continual adaptation are all routed through the same runtime line.
L1 is the fast toroidal sensory layer. In v1.0, it is used primarily for bounded simulation input and deterministic sensor packets.
L1 handles:
- grid-world observations;
- local agent position;
- heartbeat updates;
- deterministic integer sensor encoding;
- active-agent loop state.
It does not claim full real-world vision/audio/proprioception. Those require future audited encoders.
L2 stores active facts, superseded facts, and quarantined contradictions.
It supports:
- latest-state query;
- object carried-by relation;
- location chaining;
- dialog slot memory;
- correction through supersession;
- contradiction quarantine;
- evidence-linked fact records.
Examples:
FACT current_dialog_restaurant_1 has_slot_value cuisine=italian EVID d1
FACT current_dialog_restaurant_1 has_slot_value price=cheap EVID d2
QUERY current_dialog_restaurant_1 api_call_ready EVID q1
If location is missing, the runtime must ask for clarification rather than fabricate a location.
L3 stores provisional hints and rules produced by sleep/consolidation.
It is intentionally restricted:
- L3 can propose a hypothesis;
- L3 can help select a path;
- L3 can store adaptive hints;
- L3 cannot bypass proof gates;
- L3 cannot directly authorize unsupported factual answers.
A valid runtime response must still pass through proof/evidence/policy checks.
AIR is the controlled interface language used by the runtime. It prevents arbitrary text from directly becoming authority.
Typical forms:
FACT <subject> <relation> <object> EVID <evidence_id>
QUERY <subject> <query_type> EVID <evidence_id>
NEGATE <subject> <relation> <object> EVID <evidence_id>
PROC <procedure_name> ENSURES <condition> EVID <evidence_id>
Examples:
FACT mary located_in office EVID ev1
QUERY mary location EVID q1
Expected response:
ANSWER: office
Natural language can be bridged into AIR for supported bounded forms:
Mary went to the office.
Where is Mary?
Internally this becomes a controlled fact/query sequence.
Unsupported or ambiguous input should lead to:
ASK_CLARIFICATION
not hallucinated completion.
The memory layer is one of the most important parts of HTCE-Origin.
Input:
Mary went to the office.
Mary went to the garden.
Where is Mary?
Expected output:
ANSWER: garden
The old state is not erased. It becomes superseded.
Input:
Mary picked up the football.
Mary went to the garden.
Where is the football?
Expected output:
ANSWER: garden
The answer is derived from a proof chain:
carried_by(football, mary)
located_in(mary, garden)
--------------------------------
located_in(football, garden)
This is different from a parser shortcut. The runtime must preserve the chain.
Input:
I want Italian food in Rome.
Actually, make it Chinese.
Make it cheap.
Book a table.
Expected simulated action:
api_call domain=restaurant cuisine=chinese location=rome price=cheap
The correction is represented as supersession:
cuisine=italian → SUPERSEDED
cuisine=chinese → ACTIVE
HTCE-Origin uses multiple gates because no single check is sufficient.
Evidence is attached to accepted facts and proof paths. A fact without evidence cannot become an authoritative answer.
The proof layer decides whether a statement can be supported from active memory, rules, and allowed derivation patterns.
For a statement:
proof authorization can be described as:
Policy separates four cases:
ANSWER supported response
ASK_CLARIFICATION missing information
REFUSE contradiction / unsupported claim / policy block
ACT_SIMULATED proof-gated simulation-only action
Missing information is not treated as a hard refusal. It is a normal dialog step.
The topology guard checks whether state transitions remain within expected structural boundaries.
It tracks integer topological diagnostics such as Betti-style indicators and anomaly scores. A topology anomaly can block or quarantine a path.
Even if a simulated action is authorized, real action remains blocked in v1.0:
ACT_SIMULATED != ACT_REAL
HTCE-Origin v1.0 contains a bounded active-agent simulation. It is not a claim of biological life or consciousness. It is an engineering loop that gives the runtime an internal perception-action cycle.
The loop is:
heartbeat
→ L1 observation
→ Q256 world-model prediction
→ integer action scoring
→ simulated action
→ prediction error
→ homeostasis update
→ trace append
The agent can move in a small simulated grid-world, update homeostatic variables, and select actions through integer cost minimization.
Homeostasis tracks variables such as:
energy_bp
risk_bp
uncertainty_bp
novelty_bp
sleep_pressure_bp
integrity_bp
These are not subjective feelings. They are integer control variables used for simulation and safety.
The system includes a bounded sleep/consolidation mechanism.
The high-level process is:
episode
→ trace and L2 facts
→ sleep/consolidation
→ L3 provisional hints
→ next episode
→ improvement / no-regression probes
In P26/P27 development, the system demonstrated that repeated episodes can reduce cost or hold optimal cost while preserving previous knowledge.
A simplified improvement condition is:
or, after convergence:
without regression.
The v1.0 line includes multi-domain probes over:
grid_nav
dialog_slots
babi_reasoning
contradiction
The purpose is to test catastrophic interference. The runtime should not improve or update one domain while damaging another.
A probe matrix is run after consolidation cycles:
train/update grid_nav
→ probe grid_nav/dialog_slots/babi_reasoning/contradiction
train/update dialog_slots
→ probe grid_nav/dialog_slots/babi_reasoning/contradiction
train/update babi_reasoning
→ probe grid_nav/dialog_slots/babi_reasoning/contradiction
train/update contradiction
→ probe grid_nav/dialog_slots/babi_reasoning/contradiction
The release artifact reports zero-cost histories for the built-in P28 stress domains.
Every meaningful runtime event is appended to a hash-chain trace. The trace can be verified after execution.
Typical trace events include:
- runtime wake;
- fact commit;
- query;
- proof authorization;
- policy decision;
- simulated action;
- topology check;
- sleep/consolidation;
- artifact export;
- manifest verification.
The release contains:
RELEASE_MANIFEST.json
HASHES.txt
These files provide SHA-256 hashes for source and release-critical files.
The intended rule is simple:
If a critical file changes, the manifest must change, and verification must be rerun.
The clean v1.0 package reports the following verified properties in its artifacts and acceptance stages:
compileall: PASS
float_literals_in_htce_origin: 0
version_sync: PASS
invariants: PASS 16/16
release_manifest: PASS
trace_verify: PASS
topology_acceptance: PASS
hardware_width_verification: PASS
long_run_stability_smoke: PASS
benchmark: PASS 7/7
official_harness_smoke: PASS
no_leakage: PASS
v1_clean_system_revalidation: PASS
The v1.0 clean-system revalidation reports:
external_rows_passed: 15 / 15
external_false_support_count: 0
answer_key_visible_to_engine_count: 0
dialog__strict_passed: true
no_external_regression: true
proof_gates_passed: true
topology_gates_passed: true
trace_verified: true
real_actions_allowed: false
simulation_only: true
This does not prove general intelligence. It proves a bounded set of runtime properties:
- integer-only protected runtime path;
- single-runtime integration;
- proof-gated answers;
- simulation-only actions;
- no answer-key leakage in the v1.0 external-shaped test;
- dialog/action slot correction;
- contradiction quarantine;
- adaptive simulation loop;
- continual no-regression probes;
- release integrity via manifest and trace.
The following comparison is deliberately narrow and engineering-focused. It does not claim that HTCE-Origin is more fluent, larger, or more generally capable than modern language models.
| Capability | Typical LLM Prompt | Typical RAG | Agent Wrapper | HTCE-Origin v1.0 |
|---|---|---|---|---|
| Built-in evidence gate | No | Partial | Usually external | Yes |
| Proof-gated answer path | No | Rare | Usually external | Yes |
| Contradiction quarantine | No | Rare | Usually custom | Yes |
| Latest-state supersession | Prompt-dependent | Index-dependent | Custom | Yes |
| No-answer-leakage benchmark discipline | External | External | External | Built into release tests |
| Simulation-only action boundary | No | No | Custom | Yes |
| Protected trace hash-chain | No | Usually no | Custom | Yes |
| Integer-only decision core | No | No | No | Yes |
| Toroidal L1/L2/L3 state | No | No | No | Yes |
| Continual no-regression probes | No | No | Rare | Yes |
| Cross-domain regression matrix | No | No | Rare | Yes |
| Claim boundary encoded in artifacts | No | No | Rare | Yes |
The key difference is not that HTCE-Origin replaces an LLM. The key difference is that HTCE-Origin makes several safety and verification properties part of the runtime contract rather than optional wrapper behavior.
Most competing systems do not provide all of the following as a single built-in runtime assembly:
Q256 integer-only state
+ toroidal L1/L2/L3 runtime
+ fact-as-delta memory
+ active/superseded/quarantined fact status
+ proof/evidence/policy gate stack
+ topology guard
+ protected trace hash-chain
+ simulation-only action boundary
+ no-leakage benchmark discipline
+ continual no-regression probes
+ cross-domain regression matrix
This is the strongest technical value proposition of HTCE-Origin v1.0.
Representative structure:
HTCE-Origin/
├── htce_origin/
│ ├── body/
│ │ ├── runtime.py # HTCERuntime, lifecycle, living/dialog/adaptive/multitask loops
│ │ ├── layers.py # L1/L2/L3 body state
│ │ └── memory.py # fact-as-delta memory
│ ├── cognition/
│ │ ├── cortex.py # associative cortex / L3 provisional hints
│ │ ├── learning.py # consolidation support
│ │ ├── l3_promotion.py # L3 rule promotion
│ │ └── world.py # Q256 world model
│ ├── control/
│ │ ├── homeostasis.py # homeostatic integer state
│ │ └── planner.py # simulation-only planning
│ ├── evaluation/
│ │ ├── benchmarks.py # benchmark rows/reports
│ │ ├── official_harness.py # bounded official-style harness
│ │ ├── no_leakage.py # answer-key leakage checks
│ │ ├── long_run_stability.py
│ │ └── training_data.py
│ ├── governance/
│ │ ├── evidence.py # evidence/protected trace
│ │ ├── policy.py # decision policy
│ │ ├── proof.py # proof and authorization
│ │ └── snapshot.py
│ ├── kernel/
│ │ ├── core.py
│ │ ├── q16.py # Q16/Q256 compatibility layer
│ │ ├── uint256.py # bounded integer utilities
│ │ └── serialization.py
│ ├── language/
│ │ ├── air.py # AIR language
│ │ ├── parser.py
│ │ └── nlu_air_bridge.py # bounded NLU → AIR bridge
│ ├── sensory/
│ │ └── l1_encoder.py
│ └── topology/
│ ├── betti.py
│ ├── guard.py
│ └── acceptance.py
├── scripts/
│ ├── 00_gates/
│ ├── 01_sanity/
│ ├── 02_benchmarks/
│ ├── 03_topology/
│ ├── 04_hardware/
│ ├── 05_artifacts/
│ └── 06_verify/
├── tests/
├── artifacts/
├── docs/
├── RELEASE_MANIFEST.json
├── HASHES.txt
├── Makefile
└── pyproject.toml
The clean v1.0 package is intentionally lightweight.
Python >= 3.10
No required runtime dependencies in pyproject.toml
git clone <your-repository-url> htce-origin
cd htce-origin
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -e .
If you want to run tests:
pip install pytest
make acceptance
This runs the bounded release pipeline.
python scripts/00_gates/check_version_sync.py
python scripts/00_gates/scan_float_literals.py
Expected release property:
float_literals_in_htce_origin: 0
python scripts/00_gates/check_invariants.py
Expected:
16/16 invariants PASS
Depending on the script layout in your release:
python scripts/01_sanity/run_active_agent.py
or run the v1-specific artifact export/verification path:
python scripts/05_artifacts/export_artifacts.py
python scripts/06_verify/verify_trace.py
python scripts/06_verify/verify_manifest.py
The v1.0 acceptance path is organized in stages:
00_gates hard release gates
01_sanity organism/runtime sanity
02_benchmarks bounded benchmark and no-leakage checks
03_topology topology acceptance
04_hardware arithmetic hardware-width verification
05_artifacts report export
06_verify trace and manifest verification
Recommended commands:
make test
make acceptance
If a legacy test fails after an architectural update, do not simply delete it. First check whether it encodes:
- a still-valid invariant;
- an obsolete version string;
- an old artifact schema;
- a deprecated acceptance path;
- a real regression.
Only update tests when the system has genuinely moved forward and the old test checks a stale contract.
from htce_origin import HTCERuntime, RuntimeConfig, RuntimeRequest
runtime = HTCERuntime(
config=RuntimeConfig(
allow_real_actions=False,
allow_legacy_imports=False,
)
)
runtime.wake()
response = runtime.tick(RuntimeRequest(
"FACT mary located_in office EVID ev1",
source="example"
))
print(response.output)
response = runtime.tick(RuntimeRequest(
"QUERY mary location EVID q1",
source="example"
))
print(response.output)
Expected:
COMMIT: mary located_in office
ANSWER: office
runtime.tick(RuntimeRequest("Mary went to the office.", source="example"))
response = runtime.tick(RuntimeRequest("Where is Mary?", source="example"))
print(response.output)
Expected:
ANSWER: office
runtime.tick(RuntimeRequest("I want Italian food in Rome.", source="dialog"))
runtime.tick(RuntimeRequest("Actually, make it Chinese.", source="dialog"))
runtime.tick(RuntimeRequest("Make it cheap.", source="dialog"))
response = runtime.tick(RuntimeRequest("Book a table.", source="dialog"))
print(response.output)
Expected simulated action:
api_call domain=restaurant cuisine=chinese location=rome price=cheap
runtime.tick(RuntimeRequest("I want Italian food in Rome.", source="dialog"))
response = runtime.tick(RuntimeRequest("Book a table.", source="dialog"))
print(response.output)
Expected:
ASK_CLARIFICATION: missing required dialog slots: price
runtime.tick(RuntimeRequest("FACT mary located_in office EVID ev1", source="test"))
runtime.tick(RuntimeRequest("NEGATE mary located_in office EVID ev2", source="test"))
response = runtime.tick(RuntimeRequest("QUERY mary location EVID q1", source="test"))
print(response.output)
Expected behavior:
REFUSE
The exact message may vary, but it must not be a normal unsupported answer.
The v1.0 release includes artifacts such as:
artifacts/v1_clean_system_revalidation_report.json
artifacts/p25_unified_living_dialog_simulation_report.json
artifacts/p26_adaptive_policy_improvement_report.json
artifacts/p27_continual_adaptive_memory_report.json
artifacts/p28_continual_multitask_adaptive_memory_report.json
artifacts/topology_acceptance_summary.json
artifacts/hardware_width_verification_report.json
artifacts/long_run_stability_report.json
artifacts/closed_loop_trace_export.json
These artifacts are intended to support audit and technical review.
Important fields to inspect:
trace_verified
false_support_count
answer_key_visible_to_engine_count
real_actions_allowed
simulation_only
proof_gates_passed
topology_gates_passed
no_cross_domain_regression
The v1.0 clean build claims only the following bounded properties:
- Q256 integer-only protected runtime path;
- no float literals in
htce_origin
release code; - single
HTCERuntime
integration line; - L1/L2/L3 toroidal state model;
- fact-as-delta memory with active/superseded/quarantined status;
- proof/evidence/policy-gated answers;
- topology guard acceptance artifacts;
- simulation-only action boundary;
- protected trace verification;
- clean release manifest;
- bounded living active-agent simulation;
- adaptive improvement across repeated episodes;
- continual memory no-regression probes;
- multi-domain no-cross-domain-regression stress;
- external-shaped revalidation with zero answer-key visibility to engine in the built-in test.
The v1.0 clean build does not claim:
AGI
consciousness
qualia
biological life
unbounded language understanding
safe deployment in real robotics
board-measured energy performance
formal proof of correctness for every possible input
complete replacement for LLMs
Use:
HTCE-Origin is a bounded, auditable, Q256 integer-only toroidal cognitive runtime with proof-gated memory and simulation-only adaptive agency.
Do not use:
HTCE-Origin is conscious.
Do not use:
HTCE-Origin is AGI.
Do not use:
HTCE-Origin is safe for real-world autonomous control without further audit.
HTCE-Origin follows these engineering rules:
New behavior should be integrated into the existing runtime path when possible:
HTCERuntime.tick(...)
HTCERuntime.run_living_active_agent_simulation(...)
HTCERuntime.run_continual_adaptive_memory_simulation(...)
HTCERuntime.run_continual_multitask_simulation(...)
Avoid creating disconnected demonstration wrappers that bypass gates.
If the system cannot prove or support a response, it should ask for clarification or refuse.
All action paths in v1.0 are simulation-only. Real-world actuation requires a separate audited release.
If an event matters for audit, it should appear in the protected trace or release artifacts.
Do not create unnecessary parallel files. Improve the canonical runtime modules unless a new file is justified by clear separation of concern.
Old tests should not fossilize obsolete behavior. If the system advances, tests should be updated to the new contract while preserving the underlying safety invariant.
Suggested next steps:
-
larger bAbI subset;
-
repaired Dialog-bAbI task coverage;
-
MultiWOZ-style slot stress, if carefully bounded;
-
larger no-leakage report;
-
regression matrix across external rows.
-
broader but still controlled NLU-to-AIR bridge;
-
explicit ambiguity detection;
-
multilingual bounded commands;
-
better entity normalization;
-
no hidden answer leakage.
-
isolate synthesizable integer kernels;
-
prepare RTL mapping notes;
-
produce hardware claim boundary;
-
run FPGA/ASIC synthesis separately from runtime claims;
-
never report board-measured energy until physically measured.
-
richer grid-world;
-
dynamic hazards;
-
multi-agent symbolic environment;
-
longer continual-learning episodes;
-
stronger no-regression probes.
-
minimal reproducible release;
-
independent verifier script;
-
frozen benchmark seed set;
-
signed release manifest;
-
reviewer guide.
This repository may be distributed for technical review and evaluation according to the license selected by the repository owner.
If this package is intended for commercial transfer, pilot deployment, or investor review, include:
- the exact release ZIP;
RELEASE_MANIFEST.json
;HASHES.txt
;artifacts/
reports;- claim boundary document;
- acceptance command and environment notes;
- known limitations.
Commercial use should be governed by a separate agreement if the repository is not released under a permissive open-source license.
HTCE-Origin v1.0 is not a chatbot and not an AGI claim. It is a clean, bounded, auditable cognitive runtime built around integer toroidal state, proof-gated memory, protected trace, simulation-only agency, and continual no-regression validation.
Its central contribution is not raw fluency. Its central contribution is runtime discipline:
bounded input
→ integer toroidal state
→ proof/evidence/policy gates
→ topology-aware memory
→ simulation-only action
→ protected trace
→ no-regression verification
That is the system’s core identity.