Configuration in AGISystem2 is less about dozens of independent flags and more about choosing a coherent operating profile. The engine is built to behave predictably across environments such as continuous integration, manual experimentation, and production deployment. To support this, the configuration layer defines profiles that bundle together dimensionality, indexing strategies, persistence options, and recursion horizons. This chapter tells the story of those profiles and explains how they relate to the underlying geometry and to the internal tests that exercise profile selection and core math behaviour.
The smallest profile is auto_test. It is intended for fast CI runs and local smoke tests. In this profile the vector dimensionality is kept at 512, the recursion horizon is shallow so that deeply nested sentences are truncated early, and a light-weight indexing strategy such as SimHash is used. Persistence defaults to in-memory storage so that each test run starts from a clean slate and executes quickly. The point is not to capture every nuance of the conceptual space, but to verify that the basic algorithms and APIs behave as expected under deterministic conditions.
The manual_test profile enlarges the space to around 1024 dimensions and moves closer to the production configuration. It typically uses p-stable LSH tuned for L1 distance, with something like 32 hash functions grouped into 8 bands and a moderate bucket width. Persistence may write binary blobs to a temporary directory so that data can survive across a manual test session without polluting production stores. This profile is useful when you want to inspect concepts, run validation routines, or debug index behaviour without incurring the full cost of a production-scale run.
The prod profile is designed for long-lived systems. It starts at 2048 dimensions and can be raised to 4096 if you need more headroom for empirical dimensions and complex theories. The recursion horizon is kept at a value that balances expressivity and noise, often around 3 levels of nesting. Indexing uses more hashes and bands—for example 64 hashes split into 16 bands with a narrower bucket width—to obtain better recall guarantees in large knowledge bases. Persistence is configured to write binary files under a chosen root directory, potentially backed by a custom adapter if you integrate with external storage systems. All seeds, partition boundaries, and strategy choices are recorded so that runs can be replayed.
Beyond these high-level choices, profiles also set safety limits on how much work individual reasoning steps are allowed to perform. The configuration includes a maximum number of reasoning iterations for a single query and a maximum number of temporal rewind steps for time-based recall. In auto_test these caps are small, so that a mis-specified rule or an unexpected cycle cannot block CI. In manual_test and prod the limits are higher but still finite, ensuring that even pathological theory stacks eventually stop with a timeout-style result instead of hanging. These limits can be tuned explicitly, but the defaults are chosen to be safe for the intended environment of each profile.
Regardless of profile, some configuration choices are intentionally fixed. Ontology always occupies dimensions 0 to 255. Axiology always occupies 256 to 383. Everything from 384 upwards is reserved for empirical or latent dimensions discovered during ingestion and learning. These ranges are defined in the dimension catalogue and referenced by modules such as BiasController, ValidationEngine, and ConceptStore. Allowing these partitions to drift between environments would make it impossible to compare or migrate knowledge bases safely, so the engine treats them as constants.
When you inspect configuration objects in code, you will see explicit mentions of these ranges. Bias modes define which partitions they mask. Validation routines refer to ontology and axiology by index ranges when building proofs. Internal tests confirm that profiles respect the same partitioning and that adding empirical dimensions never overwrites the reserved blocks. From an operator’s perspective, this means you can safely change overall dimensionality or profile while trusting that the meaning of core axes remains stable.
Within each profile, configuration also selects an indexing and persistence strategy. For indexing, the main options are p-stable LSH tuned to L1 distance, SimHash-based schemes, or in rare experimental cases, grid-like approaches. P-stable LSH is the default for serious deployments because it respects the masked L1 geometry used throughout the engine. SimHash is faster but coarser and therefore used mostly in small tests. All index configurations specify the number of hashes, the number of bands, the bucket width, and the random seeds used to generate hash projections. These details are stored in provenance so that a particular retrieval behaviour can always be linked back to its configuration.
For persistence, the default is a binary file layout managed by Storage modules. Concepts and their diamonds are stored as compact structures on disk, with paths derived from concept identifiers. Alternative persistence modes include pure in-memory operation for tests and custom adapters for integrating with databases or object stores. The choice of persistence affects performance and durability but does not change the geometry of concepts; a concept encoded under one persistence strategy will be identical when loaded under another, as long as profiles and seeds match.
A central goal of the configuration system is to make runs reproducible. Randomness is used only in controlled places, such as generating permutation tables for relations or hash projections for LSH. All such randomness is seeded from values specified in the configuration, and those seeds are recorded in provenance whenever they influence a reasoning step. This means that if a particular retrieval result or band decision is surprising, you can rebuild an environment with the same seeds and observe the same behaviour.
From a testing perspective, this determinism is crucial. Internal suites rely on fixed seeds to assert exact numeric results. When you introduce new profiles or change hash parameters, you should extend your own tests to capture the intended behaviour. The Configuration, Explainability, and Bias & Values chapters together form a small wiki on how seeds, partitions, and strategies interact to produce a specific geometric environment.