This document turns the current project risks into concrete engineering controls.

It is intentionally project-specific: each control points at an existing subsystem,

test fixture, policy file, or implementation area in this repository.

Operating Principle

The highest-value path is to stabilize the core loop first:

[text]
Perception -> Working Memory -> Semantic Memory -> Agent Reasoning -> Typed Command Execution -> Observability

Domain modules should plug into that loop. They should not add new execution,

security, memory, or test conventions unless the core has an explicit extension

point for it.

Risk Register

ID	Risk	Impact	Current project surface	Primary mitigation
R1	Monolithic architecture	Changes become fragile; command behavior is hard to reason about	SpeechCommands.cpp, broad module set	Move new work through command registrations, facades, and feature gates
R2	Too many incomplete domain modules	Users cannot tell stable features from experiments	Many domain .cpp/.hpp files and Lua simulations	Add module maturity levels and status/self-test requirements
R3	Build and dependency complexity	Fresh builds fail; optional features block core work	Large vendored deps, CUDA/OpenCV/TensorFlow/MySQL/ImGui/Lua	Define core/full build profiles and a dependency manifest
R4	Lack of focused tests and evals	Regressions are found late or not at all	Existing –run-tests, JSON fixtures, _EvalHarness	Make tests mandatory per subsystem and add acceptance metrics
R5	Memory/search trust	Recall may be irrelevant, stale, or unverifiable	_WorkingMemory, _DatabaseFunctions, _CrossModalEpisodicEmbedder	Hybrid ranking, provenance, score thresholds, and eval sets
R6	Command execution security	Remote/local commands can cause data loss or unsafe automation	_ActiveDirectory, remote commands, shell helpers, Lua agents	Fail-closed authorization, command category policy, token hygiene, no shell injection
R7	Secrets/config exposure	Credentials leak through source, logs, or binaries	SECURITY_REVIEW.md, settings defaults, config save paths	Externalize secrets, redact logs, rotate compromised values
R8	Self-modifying/agentic changes	Bad patches or scripts can persist and run later	RSI Lua agents, source patching flows	Require explicit opt-in, sandboxed dry run, self-test pass, and human review
R9	Observability gaps	Failures are difficult to debug and compare over time	_DeveloperExtensibility::LogEvent, test logs, thread terminals	Standardize event logging, run labels, and per-thread status output

Controls By Risk

R1. Monolithic Architecture

Mitigation methods:

• Treat SpeechCommands.cpp as the compatibility dispatcher, not the place for new feature logic.
• Prefer _DeveloperExtensibility::RegisterCommand for new commands and plugins.
• Introduce narrow facade classes for shared concepts: text similarity, memory recall, command authorization, model routing, and perception snapshots.
• Require each new subsystem to expose Status, SelfTest, and HandleSpeechCommand or a registered command handler.
• Keep cross-cutting behavior centralized: policy checks in _ActiveDirectory, logs in _DeveloperExtensibility, evals in _EvalHarness, memory through memory facades.

Applied project actions:

• Use _DeveloperExtensibility as the default path for new commands.
• Keep SpeechCommands.cpp changes limited to routing, legacy compatibility, and shared safety hooks.
• Add new core helpers as small classes, for example _SimpleText, instead of adding more ad hoc helpers inside domain modules.

Acceptance checks:

• A new feature can be found by help or SearchCommands.
• A new feature has a status command and at least one fixture or builtin test.
• The feature can be disabled through policy or settings without breaking startup.

R2. Incomplete Domain Modules

Mitigation methods:

• Assign every module a maturity level: experimental, alpha, stable, or deprecated.
• Stable modules must have deterministic tests, a status command, and documented dependencies.
• Experimental modules should be opt-in and clearly separated from stable command paths.
• Use Lua/self-test scripts as simulation fixtures, but do not treat a simulation as production readiness.

Applied project actions:

• Use existing fixture patterns under tests/*.json for module self-tests.
• Add domain modules to the command help catalog only when they have a working status command.
• Keep broad domain experiments available, but route user-facing workflows through fewer polished modules.

Acceptance checks:

• Stable modules pass –run-tests <suite> or a matching fixture.
• The module reports dependency failures as status output instead of failing silently.
• Experimental modules do not run high-impact automation by default.

R3. Build And Dependency Complexity

Mitigation methods:

• Define two build profiles:
• core: command parser, memory/search, policy, settings, tests, and local text utilities.
• full: core plus perception, audio, CUDA/TensorFlow/OpenCV, GUI, agents, and integrations.
• Maintain a dependency manifest with source, version, required DLL/lib, optionality, and owning feature.
• Isolate optional dependencies behind compile-time or runtime feature gates.
• Add a smoke-build checklist that does not require every external service.

Applied project actions:

• Document build profiles in a follow-up docs/BuildProfiles.md.
• Keep tests that only need the core runnable without MySQL/network when possible.
• Use status commands to report missing optional DLLs, models, databases, and service tokens.

Acceptance checks:

• A clean checkout can run the core test suite without enabling remote commands or cloud APIs.
• Full profile failures identify the missing dependency by name and feature.
• Build logs preserve the exact profile and target used.

R4. Focused Tests And Evals

Mitigation methods:

• Use three test layers:
• Unit-style command tests through _DeveloperExtensibility::RunBuiltinTests.
• Fixture tests through tests/*.json.
• Task evals through _EvalHarness and sql/cognitive_loop_schema.sql.
• Add fixtures for each safety-critical subsystem: policy, remote commands, memory search, LLM routing, Lua execution, and file operations.
• Track pass rate by run label before and after changes.
• Never use LLM self-report as the only success signal for a task.

Applied project actions:

• Existing entry point: _AugmentedIntelligence_test.exe –run-tests.
• Existing fixtures include tests/irc_safety.json, tests/safety_ethics.json, tests/lua_selftests.json, and tests/brainstorm_runnable.json.
• Existing eval storage lives in sql/cognitive_loop_schema.sql.

Acceptance checks:

• Every high-risk change has a fixture or eval task.
• Regression threshold is explicit: no safety fixture failures, and no pass-rate drop on core evals.
• Test output is archived under tests/ or eval tables with the run label.

R5. Memory/Search Trust

Mitigation methods:

• Use hybrid search:
• lexical matching for exact words and commands,
• vector similarity for semantic recall,
• recency and source weighting for working/short/long-term memory.
• Return provenance with every recall result: source table, timestamp, score, matched keywords, and excerpt.
• Add thresholds for auto-use. Low-confidence memories should be shown as candidates, not treated as facts.
• Add negative eval cases where similar but wrong memories must not be selected.
• Keep user-visible summaries separate from raw retrieved evidence.

Applied project actions:

• Reuse _CrossModalEpisodicEmbedder::EmbedText and Similarity for semantic recall.
• Reuse _DatabaseFunctions::MemorySearchRanked for keyword-ranked recall.
• Add a _SimpleText facade as the small static text utility layer when implementing simple text scoring.
• Add memory fixtures that assert expected top result and expected non-match behavior.

Acceptance checks:

• Recall output includes score and provenance.
• Search evals include exact match, paraphrase match, stale-memory, and false-positive cases.
• Commands that act on memory require a confidence threshold or confirmation path.

R6. Command Execution Security

Mitigation methods:

• All command execution should pass through _ActiveDirectory::IsCommandAllowed or an equivalent local policy gate.
• Remote command listeners must fail closed: no token means no listener or no command execution.
• Default remote bind should be localhost unless explicitly configured.
• Do not pass LLM/user-controlled strings to shell commands. Prefer structured APIs or process creation without shell parsing.
• Treat automation, file editing, networking, database writes, and remote commands as separate high-risk categories.

Applied project actions:

• Continue using docs/EnterprisePolicy.md as the policy model.
• Use command categories from _ActiveDirectory::AuthorizeCommand.
• Remote command listeners now default to 127.0.0.1, require a configured

  token before start, deny execution when the token is empty or mismatched, and

  use constant-time token comparison.

• Remote command status and config persistence now report token presence instead

  of the raw token value.

• Track critical security items in SECURITY_REVIEW.md until fixed and retested.
• Add regression tests for denied commands, empty token behavior, blocked categories, and remote bind defaults.

Acceptance checks:

• Blocked command categories are denied before side effects.
• Empty or missing remote token does not execute a command.
• Logs record allowed/denied decisions without leaking secrets.

R7. Secrets And Configuration Exposure

Mitigation methods:

• Remove hardcoded secrets from source defaults.
• Rotate any credential that has ever been committed.
• Load secrets from environment variables, OS credential storage, or a local untracked config file.
• Redact tokens/passwords in logs, status output, and saved config.
• Restrict file permissions on local config files containing secrets.

Applied project actions:

• Use SECURITY_REVIEW.md as the active remediation list for known credential and token findings.
• Hardcoded credential defaults were removed from executable source, current

  password status output was redacted, and exposed password values in current

  generated logs/config were sanitized.

• Add a settings validation command that reports whether secrets are configured without printing values.
• Add static checks for common secret key names before release.

Acceptance checks:

• Searching source for password/token defaults finds no live secrets.
• Status output reports configured=yes/no, never the value.
• A fresh install starts with safe empty defaults and clear setup prompts.

R8. Self-Modifying And Agentic Changes

Mitigation methods:

• Source patching must be off by default.
• Generated patches must run in a staging copy first.
• Safety/ethics gate must inspect the full actionable payload, not only a truncated summary.
• The patched copy must pass self-tests before replacing the live copy.
• Human review is required for source, policy, shell, database, or network changes.

Applied project actions:

• Keep RSI source patching behind explicit flags.
• Store validation reports under generated/rsi_self_improvement/validation_reports.
• Add fixture coverage for refused patches and successful dry-run patches.

Acceptance checks:

• No self-modifying flow can update live code without an enabled flag and passing tests.
• The validation report links the patch, gate result, tests run, and rollback path.

R9. Observability Gaps

Mitigation methods:

• Standardize subsystem event names and fields.
• Every long-running thread should publish status, last action, last error, and counters.
• Use run labels for tests/evals/benchmarks so improvements are comparable over time.
• Redact secrets before logs are written.
• Preserve both user-facing output and machine-readable event records.

Applied project actions:

• Reuse _DeveloperExtensibility::LogEvent for subsystem events.
• Use the GUI thread terminal work to display per-thread status rather than scraping unstructured output only.
• Include observability expectations in module maturity requirements.

Acceptance checks:

• A failed command leaves a searchable event with subsystem, event type, message, and safe metadata.
• Thread terminals show active/inactive/error state per worker.
• Eval/test reports include run labels and pass/fail counts.

First Implementation Sequence

1. Close critical security findings from SECURITY_REVIEW.md.
2. Remove hardcoded credentials.
3. Fail closed for remote command auth.
4. Redact token logging.
5. Add policy regression fixtures.
6. Add a core reliability test pack.
7. Command policy allow/deny.
8. Safety/ethics gate.
9. Memory exact search and semantic search.
10. Simple math and simple text utilities.
11. Lua self-test dry-run.
12. Add _SimpleText as the text similarity facade.
13. Normalize/tokenize.
14. Bag-of-words cosine.
15. Jaccard/Dice/overlap.
16. Wrapper around _CrossModalEpisodicEmbedder::EmbedText.
17. Working-memory search over wm_simple_text.
18. Establish module maturity levels.
19. Start with memory, developer, policy, math, lua, perception, and remote.
20. Mark each as experimental, alpha, or stable.
21. Stable requires status, tests, and safe disable path.
22. Split build documentation into core and full profiles.
23. Document required DLLs/libs/models per profile.
24. Keep optional integrations from blocking core tests.
25. Add memory/search evals.
26. Positive exact match.
27. Positive paraphrase match.
28. Negative false-positive case.
29. Stale result case.
30. Provenance formatting check.

Release Gate

A release or large merge should not be considered stable until:

• Critical security findings are closed or explicitly disabled by default.
• –run-tests passes core, safety, and selected fixture suites.
• Memory/search eval pass rate does not regress from the prior labeled run.
• New commands are registered, documented in help, and policy-categorized.
• New modules expose status and self-test behavior.
• Logs and status output are checked for secret leakage.

Practical Focus

The project should continue to support broad experimentation, but the product

surface should be narrower:

[text]
Reliable memory + safe command execution + observable multimodal perception + extensible agents

That is the core worth hardening first. The domain modules become more valuable

when they are treated as plugins or feature modules around that reliable core.

---

Filed under: Uncategorized - @ July 18, 2026 6:50 am