Canary Builds
Control by design.
We specialize in foundational infrastructure—the invisible layer that keeps applications running smoothly. Our systems are built for organizations that need complete visibility, clear ownership, and operations that can be audited at any point. When something needs to run quietly in the background and never fail silently, that's where we come in.
Latest Projects
A governed, multi-tenant cognitive memory platform with auditable state, scoped knowledge, and intent-aware retrieval.
Frequently Asked Questions
No.
PronterLabs is not a model and does not compete with models like GPT, Claude, or Gemini.
It is a system layer that manages memory, authority, and control around reasoning agents—regardless of which model is used.
No.
PronterLabs does not fine-tune or retrain model weights using your data. Instead, it uses retrieval-augmented reasoning with governed external memory.
Your data remains:
- external to the model
- auditable
- deletable
- fully under your control
PronterLabs learns by storing validated knowledge as durable memory, not by modifying model weights.
At runtime:
- Relevant memory is retrieved
- Authority rules are applied
- The reasoning model consumes this context to generate responses
The system learns. The model remains generic.
Fine-tuning:
- permanently embeds data into model weights
- makes deletion and auditing difficult
- locks you into a specific model
- reduces long-term flexibility
PronterLabs is designed for long-lived systems, where authority, ownership, and traceability matter more than short-term optimization.
Yes.
PronterLabs is model-agnostic by design. You can use:
- cloud models
- local models
- different models for different tasks
Memory and authority remain consistent regardless of which model is active.
Your data lives in your memory layer, not inside third-party models.
Depending on your deployment, this can be:
- on-premise
- self-hosted
- within a private network
Models only receive scoped, authorized context at inference time.
Yes.
Memory ingestion can be:
- fully manual
- semi-automated with approval
- policy-driven
Every memory can include:
- provenance
- scope
- ownership
- retention rules
Nothing is remembered by default.
Yes.
Because memory is externalized:
- entries can be updated
- revoked
- scoped per user or tenant
- audited historically
This is not possible with traditional model training.
PronterLabs is built for:
- teams building long-running AI systems
- organizations that require authority and accountability
- developers who want model independence
- environments where compliance and auditability matter
It is not designed for simple chatbots or disposable AI demos.
PronterLabs is being developed as a foundational system, with components designed to be:
- modular
- interoperable
- infrastructure-grade
Specific deployment models may vary, but the architecture prioritizes ownership and control, not lock-in.
When intelligence becomes cheap, authority is not.
PronterLabs solves the problem of:
- persistent AI memory
- governed knowledge
- accountable decision-making
- continuity across models, sessions, and time
Traditional RAG focuses on document retrieval.
PronterLabs extends this into:
- governed memory
- explicit authority
- long-term continuity
- system-level learning
It is not just retrieval — it is persistent cognition infrastructure.
A server-side automation framework for rAthena with modular AI plugins, humanized behavior profiles, and multi-threaded session isolation.
Frequently Asked Questions
FalconPM operates entirely server-side through a bridge integrated into the rAthena map server. Unlike client-side bots that can be detected and banned, FalconPM is a sanctioned automation layer controlled by the server administrator, providing consistent behavior across all players with proper access.
FalconPM includes six coordinated AI modules: Hunter (task orchestrator), Merlin (combat engine), Lanner (buff manager), Amur (health/healing), Taita (loot management), and Peregrine (A* pathfinding with GAT loader). These work together through a BUFF → COMBAT → LOOT phase pipeline.
Yes. FalconPM is designed as a legal, server-owner sanctioned automation system. It integrates through a dedicated bridge layer without modifying rAthena core files, and access is gated through unlock flags controlled by server administrators.
FalconPM is released under the GNU General Public License v3 (GPLv3). This ensures the project remains free and open-source, preventing others from taking the code private and selling it without sharing improvements.
FalconPM uses a thread-pool scheduler (fpm_scheduler) sized based on std::thread::hardware_concurrency(). AI tasks execute against SessionSnapshot copies of player data, ensuring thread safety while offloading computation from the main rAthena thread. Results are applied back during the server tick loop.
Yes. The multi-session design uses a per-player session registry keyed by Account ID. Each player's automation state (phases, cooldowns, combat caches, loot timers) is isolated in a dedicated HunterController, allowing concurrent automation without interference.
Players configure automation through the Saker NPC (falconpm_config.txt) or via in-game commands like @aa, @conf, and @ov. Settings are stored as account variables, allowing configurations to persist across sessions and be modified without editing config files.
Humanization prevents automation from appearing robotic. FalconPM applies random delays, skip chances, and jitter to rotation order—all defined in delays.yml. This makes automated play indistinguishable from manual play and reduces server load from predictable action patterns.
Access is gated through unlock flags stored as account variables (#falconpm_unlocked, per-module flags, expiry timestamps). Server admins can grant access via special items, NPC flows, GM commands, or time-limited licenses, providing flexible monetization and access control.
No. FalconPM follows a strict "Bridge-Only Integration" policy. All integration happens through falconpm_bootstrap.cpp, which provides C-linkage wrappers for rAthena functions. The core rAthena codebase remains untouched beyond this bootstrap layer.
FalconPM requires a C++17 compatible toolchain (GCC, Clang, or MSVC), a MySQL-backed rAthena server compiled with -rdynamic, and libdl for runtime plugin loading on POSIX platforms. The multi-core features automatically adapt to available CPU cores.
Yes. FalconPM provides a stable API for plugin developers. Plugins are discovered from the plugins/ folder, expose a PLUGIN descriptor, and access shared functionality through the PluginContext. The API includes registration, configuration, logging, and session management utilities.
Combat uses configurable attack profiles with up to five skill slots (single-target, ground-target, or self-buffs). Mob filtering supports All/Whitelist/Blacklist modes with name or ID matching. Threat weighting from monsters.yml determines priority, and Merlin derives range heuristics from configured skills.
Phase 1 is complete: Auto-Pots, Auto-Combat, Auto-Support, Auto-Loot, and central logging. Near-term focus includes NPC dashboards and profile switching. Long-term goals cover adaptive per-map behaviors, advanced loot economics, event awareness, web dashboards, and extensible scripting hooks.