Optimando and Glassview: A Multidimensional, Evidence-Driven Architecture for Continuous AI-Assisted Software Engineering
Abstract
Modern AI-assisted coding environments can generate, explain, and modify software at increasing speed. However, they remain constrained by temporary context, repeated repository reconstruction, narrow interaction surfaces, fragmented reasoning, and limited transparency regarding why a modification was proposed or accepted.
Optimando introduces an orchestration architecture designed to transform individual coding assistants, local AI models, cloud models, analysis tools, and testing systems into coordinated components of a broader software-engineering process.
Within this architecture, Glassview serves as the code-analysis, change-intelligence, and visualization layer. A persistent multidimensional Project Wiki provides a shared project memory for developers, coding agents, background workers, and verification systems.
The proposed architecture combines:
persistent project understanding,
synchronized graph-based knowledge dimensions,
task-specific context retrieval,
local and cloud-based AI execution,
continuous background optimization,
specialized agent collaboration,
explanation-derived testing,
risk-aware code review,
and human-controlled knowledge maintenance.
Its purpose is not merely to automate coding. It is to preserve project context, reduce repeated reasoning, make software changes explainable, lower unnecessary token consumption, and support continuous improvement without removing human control.
1. The Limitations of Temporary AI Coding Context
Modern coding assistants can inspect repositories, generate patches, explain functions, and assist with debugging. Despite these capabilities, their understanding of a project is often temporary.
A coding agent may reconstruct relevant context from:
source files,
repository searches,
configuration files,
test suites,
error logs,
previous chat messages,
and temporary context windows.
This process is repeated whenever:
a new session begins,
a different model is used,
an agent process restarts,
a context window is exceeded,
a developer returns to the project after an interruption,
or a new developer joins the project.
The same architectural relationships, constraints, rejected alternatives, and security assumptions may therefore be rediscovered repeatedly.
This creates two forms of context loss.
Human context loss
Developers may lose important project understanding when they:
switch between several projects,
return to a component after weeks or months,
inspect code written by another developer,
investigate an old architectural decision,
or review changes in an unfamiliar part of the repository.
Machine context loss
AI systems may lose context when:
a conversation ends,
the available context window is exceeded,
a different model or agent is selected,
a long-running task is interrupted,
or relevant reasoning exists only in an earlier session.
In both cases, useful knowledge disappears from the active working context even though it may have already been discovered, verified, or discussed.
Optimando and Glassview are intended to counteract this repeated loss of project understanding.
2. Architectural Roles
The architecture consists of several logically distinct components.
2.1 Optimando
Optimando is the central orchestration layer.
It coordinates:
coding agents,
specialized analysis agents,
local AI models,
cloud AI models,
deterministic analysis tools,
testing systems,
persistent task queues,
background workers,
execution policies,
permissions,
model routing,
resource budgets,
and review workflows.
Optimando determines which tools or models should perform a task and under which constraints.
It may route a lightweight routine check to a local model, assign a deterministic code-analysis tool to inspect structural relationships, or request stronger reasoning from an optional cloud model when the complexity of a task requires it.
2.2 Glassview
Glassview is the code-analysis, change-intelligence, and visualization layer.
It is designed to:
inspect code changes,
map modifications to affected project entities,
retrieve relevant project knowledge,
execute predefined agent-review logic,
aggregate findings from multiple sources,
visualize dependencies and risks,
expose conflicting conclusions,
and present evidence to developers.
Glassview does not merely show which lines changed. It is intended to explain why those changes matter within the wider project.
2.3 The Project Wiki and Project Memory
The Project Wiki provides a persistent human-readable and machine-readable representation of the project.
For ordinary projects, it may contain:
objectives,
requirements,
terminology,
workflows,
milestones,
decisions,
constraints,
responsibilities,
risks,
and historical changes.
For software projects, it can be extended into a multidimensional project memory in which different forms of knowledge are maintained as distinct but synchronized graph dimensions.
2.4 WRCode Developer Kit
The WRCode Developer Kit provides the technical components required to connect:
repositories,
coding environments,
agent interfaces,
testing frameworks,
automation systems,
version-control platforms,
and project-memory services.
It acts as an integration and development layer supporting the broader Optimando architecture.
3. From Isolated Coding Assistants to Orchestrated Development
Conventional AI coding assistants frequently operate as isolated tools.
A developer submits a prompt, the assistant inspects part of the repository, and a proposed modification is returned. The developer must then determine:
whether the assistant understood the architecture,
whether important dependencies were overlooked,
whether a security assumption was violated,
whether a similar approach had previously failed,
whether the explanation matches the actual code,
and whether the modification requires additional testing.
Optimando changes this interaction model by treating coding assistants as contributors within an orchestrated process.
A proposed modification can be passed through several coordinated stages:
Task interpretation
Project-context retrieval
Structural code analysis
Specialized agent review
Risk and security assessment
Test generation or selection
Execution and evidence collection
Human review
Project-memory update
This approach shifts AI assistance away from a single request-and-response interaction and toward a traceable software-engineering workflow.
4. Specialized AI Agents and Division of Cognitive Labor
The architecture is designed to support specialized agents with clearly defined responsibilities.
The objective is not to ask several models the same question and treat agreement as proof. Each agent should instead contribute a distinct analytical function, evidence source, or verification perspective.
4.1 Fault-Localization Agents
Fault-localization agents identify code regions that may be responsible for:
persistent defects,
failed tests,
runtime anomalies,
unexpected behavior,
or regressions.
Their task may be limited to reducing the search space rather than directly generating a fix.
4.2 Architecture Agents
Architecture agents inspect:
module boundaries,
dependency direction,
coupling,
cyclic relationships,
interface stability,
separation of concerns,
and architectural drift.
They can compare current implementation structures with documented architectural intentions.
4.3 Security and Trust Agents
Security-oriented agents examine:
authentication,
authorization,
secrets,
trust boundaries,
permission checks,
sensitive data flows,
sandbox boundaries,
external communication,
unsafe execution paths,
and security invariants.
4.4 Risk-Analysis Agents
Risk agents evaluate findings according to:
affected assets,
likelihood,
severity,
potential impact,
mitigation options,
detectability,
residual risk,
and confidence.
A technical security condition and its associated business or operational risk remain separate but connected concepts.
4.5 Testing and Verification Agents
Verification agents translate claims into:
unit tests,
integration tests,
end-to-end tests,
security tests,
benchmarks,
property checks,
assertions,
static-analysis rules,
or acceptance criteria.
4.6 External-Knowledge Agents
External-knowledge agents retrieve:
technical documentation,
scientific research,
standards,
public reference implementations,
security guidance,
and relevant engineering practices.
External information remains evidence. It does not automatically become authoritative project knowledge.
4.7 Cross-Reference Agents
Cross-reference agents compare external knowledge with the local project.
They may identify:
structural similarities,
important deviations,
missing safeguards,
potentially useful methods,
or unsupported assumptions.
4.8 Runtime-Analysis Agents
Runtime agents inspect:
logs,
traces,
exceptions,
metrics,
performance measurements,
observed execution paths,
and production anomalies.
This allows the architecture to compare intended, implemented, tested, and observed behavior.
4.9 Knowledge-Maintenance Agents
Knowledge-maintenance agents examine the Project Wiki itself.
They may identify:
outdated entries,
missing relationships,
duplicated explanations,
inconsistent terminology,
undocumented components,
contradictions,
or rationale records that no longer match the code.
Many of these tasks can be performed by smaller local models.
5. A Multidimensional Project Memory
The central architectural concept is a project memory composed of multiple related knowledge dimensions.
These dimensions may be implemented as separate graphs, graph namespaces, or logically isolated schemas. They remain synchronized through shared project entities and stable identifiers.
Each dimension may have its own:
update process,
provenance rules,
verification requirements,
confidence model,
permissions,
freshness states,
and data sources.
The purpose is not to store every form of knowledge in one undifferentiated graph.
The purpose is to preserve distinct perspectives while allowing relationships to be traversed across them.
5.1 Project and Requirements Dimension
The Project Wiki dimension contains the high-level project context.
It may include:
project objectives,
functional requirements,
non-functional requirements,
terminology,
user roles,
workflows,
milestones,
ownership,
constraints,
acceptance criteria,
and planned capabilities.
This dimension explains what the project is intended to achieve.
It provides context that may not be visible in the source code.
5.2 Structural Code Dimension
The structural code dimension represents the observable organization of the software.
It may contain:
repositories,
files,
modules,
packages,
classes,
functions,
methods,
interfaces,
imports,
function calls,
inheritance relationships,
API routes,
data flows,
configuration elements,
tests,
and version-control relationships.
This dimension answers:
What exists, where does it exist, and how is it connected?
Whenever possible, structural facts should be derived through deterministic mechanisms such as:
parsers,
abstract syntax trees,
language servers,
dependency analyzers,
build metadata,
version-control history,
and runtime instrumentation.
AI-generated interpretations should not replace directly observable evidence where reliable deterministic extraction is available.
5.3 Intent and Rationale Dimension
The intent and rationale dimension explains what a component is supposed to do and why it was designed in a particular way.
It may include:
component purpose,
expected behavior,
architectural reasoning,
assumptions,
invariants,
rejected alternatives,
known limitations,
compatibility requirements,
performance considerations,
and historical constraints.
For example, the structural graph may indicate that an authentication controller calls an authentication service.
The rationale dimension may explain that authentication logic was intentionally separated from the controller in order to:
centralize rate limiting,
maintain transport independence,
enforce consistent auditing,
and prevent credential-handling logic from spreading across the application.
This type of knowledge is difficult to infer reliably from code alone.
5.4 Risk Dimension
The risk dimension records possible adverse outcomes connected to:
components,
changes,
dependencies,
architectural decisions,
operational conditions,
and unresolved findings.
A risk entry may contain:
affected assets,
failure or threat scenario,
likelihood,
severity,
potential impact,
detectability,
mitigation status,
compensating controls,
residual risk,
responsible reviewer,
and confidence.
Risks may concern:
security,
reliability,
maintainability,
performance,
data loss,
operational continuity,
vendor dependency,
compliance,
or architectural complexity.
5.5 Security and Trust Dimension
The security and trust dimension represents the security-relevant structure of the project.
It may include:
trust zones,
trust boundaries,
identities,
principals,
roles,
permissions,
authentication mechanisms,
authorization rules,
secrets,
credentials,
data classifications,
sensitive data flows,
network boundaries,
sandbox boundaries,
attack surfaces,
required controls,
and security invariants.
A simplified security path might be represented as:
User-controlled input
→ crosses an external trust boundary
→ reaches an API route
→ is validated by an input policy
→ is processed within an isolated component
→ produces an auditable security event
If a code change removes validation or audit logging, Glassview can connect that modification to the corresponding security structure.
5.6 Test and Verification Dimension
The test and verification dimension connects requirements, claims, risks, invariants, and code entities to executable evidence.
It may contain:
unit tests,
integration tests,
end-to-end tests,
browser tests,
security tests,
property-based tests,
benchmarks,
static-analysis rules,
assertions,
acceptance criteria,
test results,
and verification history.
This dimension enables questions such as:
Which test verifies this security invariant?
Which architectural claim has no executable evidence?
Which mitigation exists only as documentation?
Which modified component is insufficiently covered?
Which test became obsolete after a refactoring?
A test is therefore linked not only to a file or function, but also to the claim it is intended to verify.
5.7 Runtime and Observability Dimension
The runtime and observability dimension records actual system behavior.
It may connect project entities with:
logs,
traces,
metrics,
exceptions,
resource consumption,
observed execution paths,
latency measurements,
deployment environments,
and production anomalies.
This creates a distinction between:
intended behavior,
implemented behavior,
tested behavior,
and observed behavior.
A component may appear correct structurally while runtime evidence reveals that:
an error path is frequently triggered,
a control is bypassed,
a dynamic dependency is loaded,
or a performance assumption is false.
5.8 Dependency and Supply-Chain Dimension
The dependency and supply-chain dimension represents external software and infrastructure relationships.
It may include:
direct dependencies,
transitive dependencies,
package versions,
licenses,
software bills of materials,
vulnerabilities,
container images,
build tools,
external APIs,
model providers,
update history,
and deployment dependencies.
This dimension can support:
vulnerability analysis,
dependency-risk assessment,
license review,
impact analysis,
replacement planning,
and update prioritization.
5.9 Change and History Dimension
The change and history dimension records how the project evolved.
It may contain:
commits,
branches,
pull requests,
patches,
releases,
migrations,
refactorings,
incidents,
accepted proposals,
rejected proposals,
superseded decisions,
and previous failed approaches.
This dimension can answer:
Why was this component introduced?
Which incident led to this security rule?
Was this implementation strategy previously attempted?
Which architectural decision replaced an older one?
When did a particular constraint become relevant?
Historical project knowledge helps prevent repeated mistakes and unnecessary rediscovery.
5.10 Evidence and Gap Dimension
The evidence and gap dimension connects internal project decisions with external knowledge and unresolved questions.
It may contain:
scientific publications,
technical standards,
public reference implementations,
engineering guidance,
security recommendations,
benchmarks,
unresolved assumptions,
and known evidence gaps.
A gap may represent:
an architectural assumption that has not been validated,
a security claim without a corresponding test,
an implementation that differs from a standard,
missing empirical evidence,
an unresolved performance question,
an insufficiently documented decision,
or a method that has not yet been evaluated for the project.
This dimension should be applied selectively to technically significant areas rather than indiscriminately to every function.
5.11 Optional Future Dimensions
The architecture is intended to remain extensible.
Additional dimensions may later include:
compliance and legal requirements,
privacy and data-governance rules,
user-experience decisions,
deployment topology,
cost and resource consumption,
incident-response knowledge,
ownership and responsibility,
or product-specific domain knowledge.
The key principle is that each dimension should represent a meaningful form of project knowledge with clear relationships to shared project entities.
6. Shared Identity, Provenance, and Freshness
The graph dimensions remain separate but refer to shared entities through stable identifiers.
A component such as AuthenticationService may therefore be represented across several dimensions.
Shared entity: AuthenticationService
Structural code:
- called by LoginController
- uses CredentialRepository
- invokes AuditLogger
Intent and rationale:
- centralizes authentication policy
- must remain transport-independent
- must not reveal account existence
Security and trust:
- processes credentials
- crosses a trust boundary
- requires rate limiting and auditing
Risk:
- credential disclosure
- account enumeration
- replay or privilege-escalation risk
Verification:
- covered by authentication integration tests
- audit invariant verified by SecurityTest-22
Runtime:
- observed latency
- failed-login frequency
- exception paths
Evidence and gaps:
- linked security guidance
- recovery process not fully evaluated
Each knowledge item may include provenance such as:
author or generating agent,
model,
tool,
creation time,
referenced repository revision,
confidence,
review status,
and supporting evidence.
Possible states include:
generated,
queued for review,
under investigation,
verified,
stale,
contradicted,
superseded,
historical,
and unresolved.
Persistent project knowledge becomes dangerous if it appears authoritative after the underlying code has changed.
When a relevant entity changes, associated entries can therefore be marked as potentially stale.
Verified knowledge should not be silently replaced. The system should instead produce a proposed revision and display the difference between the existing and newly inferred interpretation.
7. Project-Aware Context Retrieval
The multidimensional Project Wiki enables a different approach to agent context.
Instead of searching the entire repository for every task, a coding agent can first request a task-specific context package.
This package may contain:
relevant project objectives,
affected components,
connected code entities,
architectural decisions,
applicable invariants,
security boundaries,
known risks,
relevant tests,
runtime evidence,
previous changes,
and unresolved gaps.
A possible retrieval sequence is:
A developer or coding agent submits a task.
The project-memory service identifies relevant entities and concepts.
The structural graph returns related symbols, dependencies, and tests.
The rationale graph supplies intended behavior and architectural decisions.
The security and risk dimensions identify relevant boundaries and threats.
The verification dimension identifies existing or missing evidence.
Runtime information is added where relevant.
The evidence and gap dimension supplies external references and unresolved questions.
A compact context package is assembled according to a defined token or information budget.
The coding agent inspects only the relevant source-code areas and expands the search if necessary.
Glassview evaluates the resulting modification against the same project context.
The source code remains authoritative for the implementation.
The Project Wiki does not replace code inspection. It provides an orientation layer that reduces unnecessary repository traversal and repeated reasoning.
8. Reducing Context Breaks and Token Consumption
The architecture is intended to preserve useful reasoning across:
sessions,
developers,
models,
agents,
interrupted tasks,
and long-running workflows.
Without persistent project memory, each new agent may need to reconstruct:
component purposes,
architectural relationships,
security assumptions,
historical decisions,
and previous failed approaches.
This repeated reconstruction consumes time, compute, and tokens.
A persistent project memory allows the system to reuse verified knowledge.
Instead of repeatedly sending large portions of the repository to a model, Optimando can assemble a smaller task-specific context package.
Potential benefits include:
fewer unnecessary file reads,
smaller prompts,
lower token consumption,
faster project orientation,
improved continuity between sessions,
and more consistent decisions across different agents.
This does not eliminate the need for source-code access. It allows code access to become more targeted.
The project memory therefore functions as a shared orientation layer for both humans and machines.
9. Local and Cloud-Based AI Execution
Optimando is designed to support local models, cloud models, and controlled hybrid workflows.
The objective is to assign each task to the least expensive and least intrusive capable execution path.
A possible hierarchy is:
Deterministic tools and rules
→ lightweight local model
→ stronger local model
→ optional cloud model
→ human decision
9.1 Deterministic Tools First
Tasks that can be solved reliably through:
parsing,
graph traversal,
static analysis,
rule evaluation,
dependency inspection,
or test execution
should not automatically be delegated to a generative model.
Deterministic tools provide reproducible evidence and reduce unnecessary AI usage.
9.2 Lightweight Local Models for Routine Tasks
Smaller local models can perform continuous or frequently repeated checks that do not require extreme computational resources.
Suitable tasks may include:
identifying undocumented new functions,
detecting potentially stale rationale entries,
checking terminology consistency,
comparing documentation with simple code changes,
classifying logs and error messages,
summarizing small diffs,
mapping tests to changed components,
identifying duplicate or contradictory wiki entries,
reviewing dependency metadata,
prioritizing routine analysis tasks,
detecting missing relationships between graph dimensions,
generating first-pass documentation proposals,
and performing predefined low-complexity security checks.
Local execution is particularly useful for:
private repositories,
internal documentation,
sensitive logs,
proprietary architecture,
and continuous background processing.
These models can remain available without transmitting source code to an external provider.
9.3 Stronger Local Models
Where sufficient local hardware is available, stronger local models may perform:
multi-file reasoning,
architectural analysis,
complex code review,
deeper fault localization,
test generation,
and structured refactoring proposals.
9.4 Optional Cloud Models
Cloud AI may be activated when a task requires:
stronger general reasoning,
large-context analysis,
external research,
complex architectural comparison,
advanced threat modeling,
scientific literature analysis,
difficult multi-stage debugging,
conflict resolution between several findings,
or evaluation of a large refactoring strategy.
Cloud execution should remain policy-controlled.
Only the necessary and permitted context should be transmitted.
A hybrid workflow may keep the private repository local while allowing a cloud research agent to investigate:
public standards,
scientific publications,
open-source reference implementations,
or publicly documented security practices.
The resulting external findings can then be returned to the local environment without exposing the entire codebase.
10. Persistent Task Queues and Background Optimization
Long-running optimization should not be implemented as one unstructured conversation with a model.
Optimando may instead maintain persistent analysis queues containing well-defined tasks.
A task may specify:
project,
repository,
branch or commit,
relevant graph dimensions,
permitted tools,
execution model,
priority,
dependencies,
time budget,
compute budget,
token budget,
network permissions,
and required review level.
Possible queue states include:
pending,
running,
paused,
blocked,
awaiting evidence,
awaiting review,
completed,
rejected,
or superseded.
Intermediate findings can be stored as structured artifacts.
This allows:
an interrupted task to resume,
a second agent to continue the work,
a stronger model to review a local model’s result,
or a developer to inspect the analysis before further processing.
11. Persistent Background Optimization and Long-Horizon Analysis
Glassview is not limited to reactive analysis triggered by an individual code change or developer request.
A planned capability is the execution of extended analytical sessions in which local or cloud-based AI systems examine a project over longer periods.
These sessions may run:
overnight,
during idle system capacity,
after new commits,
after dependency updates,
before releases,
on a defined schedule,
or in response to newly detected risks.
This long-horizon mode allows larger problems to be decomposed into smaller analytical jobs rather than requiring one model to produce an immediate complete answer.
Possible background tasks include:
architectural consistency analysis,
security and trust-boundary review,
dependency-risk analysis,
identification of insufficiently tested components,
detection of outdated rationale entries,
comparison between documented intent and actual implementation,
technical-debt discovery,
performance-optimization analysis,
scientific and technical gap analysis,
unresolved-question review,
runtime anomaly analysis,
supply-chain review,
and generation of proposed Project Wiki updates.
Permanent background analysis does not require a model to run at full load continuously.
Optimando can use:
event-based triggers,
periodic schedules,
low-priority queues,
idle-resource detection,
and task batching.
A lightweight local model may continuously process inexpensive routine checks while more demanding tasks remain queued for a stronger local or cloud model.
12. Background Security and Risk Analysis
Security analysis benefits from long-running execution because many risks are not visible within an isolated code fragment.
A background security workflow may:
traverse the code graph,
inspect trust boundaries,
follow sensitive data flows,
compare authorization checks,
detect changes to permission paths,
inspect dependency updates,
identify unsafe tool execution,
analyze secret handling,
and connect findings to documented security invariants.
Separate agents may examine:
authorization,
data exposure,
injection risks,
sandbox escape paths,
supply-chain dependencies,
secrets,
unintended network communication,
and unsafe execution capabilities.
Glassview can present:
the finding,
supporting code references,
affected entities,
related risks,
confidence,
conflicting agent conclusions,
and missing verification evidence.
13. Continuous Gap Analysis
The evidence and gap dimension provides a persistent work surface for long-term investigation.
Background agents may periodically revisit gaps as:
the codebase changes,
new models become available,
scientific research evolves,
standards are updated,
or project requirements change.
A gap may move through states such as:
unidentified,
detected,
queued,
under investigation,
partially supported,
contradicted,
resolved,
or requiring human judgment.
Examples include:
a security assumption without an executable test,
a performance claim without benchmark evidence,
an architectural decision without rationale,
an implementation differing from a standard,
or a documented mitigation that is no longer present in code.
14. Evidence Accumulation Rather Than Unrestricted Autonomy
The purpose of background optimization is not to allow an AI system to modify a project invisibly.
By default, background agents should operate on:
a defined repository snapshot,
a specific commit,
an isolated branch,
or a read-only project view.
Their outputs may include:
identified risks,
supporting references,
graph paths,
test proposals,
rationale revisions,
architecture alternatives,
confidence assessments,
unresolved questions,
candidate patches,
and documentation updates.
These outputs can then be reviewed through Glassview.
Verified project knowledge should not be silently replaced.
If an agent reaches a conclusion that conflicts with an existing architectural decision or security invariant, the conflict should be displayed explicitly.
High-assurance projects may restrict agents to read-only analysis.
Other environments may permit agents to create:
branches,
patches,
tests,
or documentation proposals,
while still requiring human approval before integration.
15. Transforming AI Explanations Into Executable Tests
AI explanations can be treated as provisional engineering claims.
For example, an explanation may claim that:
a function validates credentials,
a refactoring preserves behavior,
a change improves performance,
or a security boundary remains intact.
Glassview can translate these claims into:
test cases,
assertions,
benchmarks,
static-analysis rules,
validation procedures,
or observable acceptance conditions.
If an explanation states that credentials are validated, tests may be generated for:
valid input,
invalid input,
malformed input,
repeated attempts,
missing fields,
and boundary conditions.
If an explanation claims improved performance, the modified component may be benchmarked against a previous baseline.
If an explanation claims that a security property remains unchanged, relevant boundary and authorization tests may be executed.
A passing test does not prove that an explanation is complete. It provides evidence regarding a specific claim.
Verified explanations may later contribute to the rationale dimension.
Contradicted explanations may be:
rejected,
revised,
or retained as historical records of an unsuccessful approach.
16. Glassview as an Explainable Change-Intelligence Layer
When a code modification is detected, Glassview can map the changed lines to shared project entities.
It can then retrieve information from several graph dimensions.
A change report may include:
modified files and symbols,
direct and indirect dependencies,
potentially affected behavior,
architectural decisions,
applicable invariants,
security boundaries,
known risks,
associated tests,
runtime evidence,
stale documentation,
supply-chain implications,
and unresolved gaps.
For example, removing an audit-logging call may appear locally harmless.
Glassview may discover that:
the affected function handles authentication,
complete authentication-event auditing is a documented invariant,
the risk dimension associates missing audit events with incident-detection failure,
the verification dimension contains no test for that invariant,
and the runtime dimension depends on the resulting events for monitoring.
Glassview can therefore present a traceable chain:
Code change
→ affected component
→ violated invariant
→ associated security risk
→ missing verification
→ proposed test
→ human decision
This is more informative than a binary approval score or an unexplained AI recommendation.
17. Continuous Project Learning
The Project Wiki and Glassview can form a controlled optimization loop.
Project knowledge
→ task-specific context
→ code or analysis activity
→ Glassview review
→ tests and evidence
→ human decision
→ approved knowledge update
→ improved future context
The Project Wiki supplies context for development.
Glassview uses that context to evaluate changes.
Accepted modifications, verified explanations, new tests, identified risks, and discovered constraints can then be proposed as updates to the project memory.
This process allows the project memory to evolve alongside the codebase without treating AI-generated interpretations as automatically authoritative.
Over time, the system may reduce repeated rediscovery of:
architectural reasoning,
previous failures,
security assumptions,
rejected strategies,
dependency relationships,
operational knowledge,
and project-specific conventions.
18. Transparency for Humans and Machines
The system is designed to make project knowledge accessible at different levels of detail.
A developer may request:
a concise change summary,
a component overview,
a risk report,
a security analysis,
a complete reasoning chain,
or the underlying graph relationships.
A coding agent may retrieve the same knowledge in structured form.
This creates transparency for both humans and machines.
Humans gain:
clearer project orientation,
explainable code reviews,
access to historical reasoning,
and better visibility into uncertainty.
Machines gain:
reusable project context,
structured constraints,
verified relationships,
and smaller, more relevant context packages.
The same underlying project memory can therefore support:
onboarding,
debugging,
planning,
code generation,
testing,
review,
maintenance,
and long-running analysis.
19. Resource and Scope Governance
Every interactive or background task may operate under an execution policy.
This policy may define:
permitted repositories,
allowed branches,
accessible graph dimensions,
available tools,
approved models,
maximum runtime,
compute limits,
token budgets,
network access,
data-export restrictions,
write permissions,
and required approval levels.
A sensitive repository may permit:
deterministic tools,
local models,
read-only analysis,
and local test execution,
while prohibiting cloud transmission.
Another project may allow cloud-based external research without allowing the model to access private source code.
This policy-based approach allows the same architecture to support both flexible development and high-assurance environments.
20. Example Overnight Workflow
A typical overnight analysis may proceed as follows:
A repository commit or snapshot is selected.
Optimando identifies scheduled and unresolved analysis tasks.
Deterministic tools perform structural and rule-based checks.
Lightweight local models process routine tasks.
More complex findings are escalated to stronger local models.
Optional cloud models handle permitted high-reasoning or external-research tasks.
Results are mapped to code entities, risks, security properties, tests, rationale entries, and gaps.
Conflicting conclusions remain visible instead of being merged into artificial consensus.
Candidate tests, patches, documentation updates, and gap records are generated.
Glassview assembles a reviewable report.
A developer decides which findings should be rejected, investigated, implemented, or incorporated into the Project Wiki.
This enables useful optimization work to continue outside the immediate coding session while preserving human control over the codebase and its authoritative knowledge.
21. Intended Benefits
The proposed architecture is intended to provide several practical benefits.
Faster project understanding
Developers and coding agents can begin with relevant project context rather than reconstructing the entire system.
Reduced context loss
Important reasoning can persist across sessions, models, agents, and developers.
Lower token consumption
Task-specific context packages can reduce repeated transfer of large repository sections.
Continuous routine analysis
Local models can process low-cost checks continuously or during idle periods.
Selective use of stronger models
Cloud or high-capability local models can be reserved for tasks requiring substantial reasoning.
Explainable change analysis
Glassview can present why a change matters and which evidence supports the conclusion.
Improved project knowledge
Accepted findings can strengthen the Project Wiki over time.
Human control
Agents may produce evidence, proposals, and candidate changes without receiving unrestricted authority over the project.
22. Development Status
The architecture described in this article contains both existing concepts and planned future capabilities.
The following elements represent roadmap components whose implementation and technical validation may remain incomplete:
the multidimensional Project Wiki,
synchronized graph dimensions,
persistent rationale and intent records,
project-aware agent context retrieval,
continuous local AI maintenance,
cloud reasoning escalation,
persistent background queues,
scientific gap analysis,
and automated cross-dimensional freshness detection.
The purpose of this publication is to document the intended architecture, its internal relationships, and its potential development direction.
It should not be interpreted as evidence that every described component has already been implemented, validated, or released.
The central architectural objective is to create a persistent and explainable software-engineering environment in which human developers and AI systems can build upon existing project knowledge rather than repeatedly reconstructing it from the beginning.
