TIMBOTIC / Field report
Building TIMBOT: search is not evidence
Since the first TIMBOT post, most of the work has gone into making the system less careless.
The biggest change came from a simple failure.
I asked TIMBOT:
Do a websearch and tell me about the best 32gig+ video cards I can buy
It searched the web, found current GPU articles, retailer listings and high-VRAM pages, then replied:
The requested information could not be verified from available evidence.
That was useful because the search itself had worked.
The problem was deciding whether the retrieved material actually answered the question.
Freshness
TIMBOT now detects requests that depend on current information, such as:
latest, current, today, recent, newest, available now, current price
A trusted system clock supplies the current date and TIMBOT treats its internal model knowledge as potentially stale.
If web access is allowed, it searches and evaluates whether the evidence is recent enough for the question.
The logic is deterministic and does not require another model call.
This fixed one problem and exposed another.
Product research does not always have useful publication dates.
An official specification page can still verify that a GPU has 32 GB of VRAM. A live retailer page can show that a product is currently listed. A recent review can help compare performance.
TIMBOT now treats specifications, listings, reviews and release events differently.
Evidence quality
Search results now receive a small quality state:
goodpartialstaleconflictinginsufficient
Stale or insufficient evidence can trigger one reformulated search.
Partial evidence can still produce a useful partial answer.
Conflicting evidence can be shown as a disagreement instead of quietly choosing one source.
The checks are mostly deterministic and deliberately bounded.
The 32 GB GPU problem also exposed something more subtle.
TIMBOT could find a good GPU review and separately find the phrase 32GB, but that did not prove the reviewed card actually had 32 GB.
The current GPU research path now tries to bind the required memory capacity to a named product before recommending it.
That logic is fairly specific to GPU research, but the lesson is useful elsewhere.
Facts need identity.
Memory now has some history
TIMBOT's memory still uses SQLite and FTS5.
I have resisted adding a vector database because the current system remains small, fast and understandable.
Memory now keeps observation history when a trusted keyed fact changes.
A newer value can become current while the previous value remains available as historical information.
TIMBOT also records a small amount of source information, such as whether the fact came from confirmed user input or a trusted backend path.
This matters because facts change.
A machine gets replaced. A software version changes. A product stops being current.
Deleting the old value every time loses useful context.
The temporal system is still conservative. It does not attempt broad semantic reconciliation between unrelated memory keys, and newer information does not automatically win purely because of its timestamp.
Text-to-CAD
I also added a local text-to-CAD experiment using cadgen and build123d.
TIMBOT produces a constrained geometry recipe containing supported shapes, transforms and Boolean operations. A separate CAD service validates that recipe and generates STEP, STL, GLB and 3MF files.
The safety architecture is probably more interesting than the current modelling capability.
The model does not receive a general Python execution tool. It works through a limited geometry format which is compiled by trusted code.
The current CAD capability is fairly basic.
It handles boxes, cylinders, spheres, truncated cones, rotation, translation, union, subtraction and intersection.
That is enough for simple plates, holes and primitive mechanical parts.
It still lacks the richer operations that make CAD genuinely useful for me, such as sketches, fillets, threads, assemblies and more capable parametric modelling.
So far I would call the text-to-CAD implementation interesting but underwhelming.
Maybe it improves as the underlying tools mature.
Generated files have different lifecycles
TIMBOT now has several generation systems and they all behave differently.
Replicate image jobs mainly keep remote prediction references.
Tim stores generated images locally.
Meshy keeps remote task references.
CAD keeps exported geometry in its own persistent volume.
That matters for backups, deletion and retries.
A generation timeout can also be awkward if the remote provider may already have accepted a paid job.
For those paths TIMBOT avoids blindly repeating uncertain submissions.
Security has grown too
The current source also includes account authentication, Argon2 password hashing, TOTP, recovery codes, sessions, CSRF checks and origin validation.
TIMBOT is still a single-owner system.
I have no interest in turning it into a public multi-user platform, but the security around the private interface is considerably stronger than the early gateway-only setup.
Still keeping it small
TIMBOT currently has 17 registered tool names when every optional integration is enabled.
Local context defaults to 16,384 tokens, tool rounds default to six, search retries remain bounded, and external MCP catalogues are discovered only when needed.
There is still no autonomous background agent, multi-agent swarm or giant planning framework.
I am happy with that.
Consumer hardware running a decent local model can already do a surprising amount when the surrounding system handles permissions, retrieval, memory and tools properly.
That still feels like the most interesting part of TIMBOT.
The model matters, but the surrounding architecture determines whether its answer is actually useful.