Technical model · Evidence before inference

Every material conclusion should be traceable back to what the system actually contains.

This evidence model is led by Lavan Nallainathan, Harten's founder and a former Microsoft Director.

Harten is being designed around a simple constraint: an AI recommendation is not evidence. Deterministic analysis establishes observable facts first; machine reasoning then works over those facts with uncertainty and provenance retained.

The result is a software graph that connects source evidence to technical risk, modernisation decisions and controlled implementation.

01 · Source facts

Start with analyzers, parsers and observable structure.

Different technologies require different analysis techniques. Harten's model is tool-neutral: use the strongest available evidence source, then normalize the result.

StructureCode

Languages, frameworks, symbols and dependency structure

Repository layout, projects, modules, functions, classes, packages and static dependency relationships become explicit evidence rather than assumptions.

BehaviourExecution

Call paths, integrations and data access

Where analysis permits it, calls, API boundaries, database interactions, external dependencies and configuration links are connected into system behaviour.

RiskEngineering

Security, supportability, test and complexity signals

Unsupported frameworks, risky dependencies, test gaps, coupling, duplicated logic and other engineering signals are retained with their source and confidence.

ContextEstate

Technical records can extend what source alone can prove

Architecture records, API definitions, schemas, build configuration, deployment metadata and approved estate records can enrich the graph without being silently treated as code truth.

Evidence record

A finding should carry its own audit trail.

  • Location: repository, path, symbol or technical source where the fact originated.
  • Finding: the observable condition or relationship.
  • Method: analyzer, rule, parser or reasoning step that produced it.
  • Confidence: what is known, inferred, incomplete or disputed.
  • Decision link: which risk, disposition or transformation recommendation relies on it.

02 · Software graph

Files become a model of the system they form.

The graph is intended to preserve both technical structure and the relationships that make change risky.

NodeApplication

Applications and bounded contexts

Logical systems and ownership boundaries provide a higher-level view than repositories alone.

NodeLogic

Components and business rules

Important logic can be linked to the code, stored procedures, configuration or services that implement it.

EdgeDependency

Calls, reads, writes and integration relationships

Relationships expose blast radius and sequencing constraints that are easily hidden when tools report findings one file at a time.

OverlayDecision

Risk, disposition, confidence and ownership

The same graph can carry modernisation decisions, unresolved questions and accountable owners alongside the technical evidence.

03 · Decision

Modernisation recommendations should be explainable, not merely plausible.

A disposition is a hypothesis backed by evidence and confidence, not a label generated because a framework appears old.

01

Observe

Capture source facts and estate constraints.

02

Reason

Connect technical evidence to risk, economics and options.

03

Challenge

Expose weak evidence, competing interpretations and unknowns.

04

Decide

Record the chosen action, owner, confidence and conditions for reversal.

04 · Governed transformation

The evidence chain continues after the decision.

  • Bounded context: transformation operates against an explicit slice rather than the entire estate.
  • Implementation evidence: generated or modified code remains tied to the intended change.
  • Validation: build, tests, security checks and regression evidence are attached to the change.
  • Independent critique: material output receives separate challenge before approval.
  • Human gate: accountable people retain authority over release, risk acceptance and stop decisions.

Public boundary

No customer proof is required to explain the technical model.

Public Harten examples are synthetic. Product claims will be demonstrated through reproducible technical examples and future Harten-originated evidence rather than confidential client or employer material.

Synthetic estate

Inspect the worked decision example

The current example uses invented systems, figures and recommendations to demonstrate the decision structure without exposing a real estate.

Open the synthetic example

Future benchmark

A reproducible legacy benchmark is the stronger proof

The product direction is to demonstrate analysis and transformation against purpose-built legacy applications whose source and expected outcomes can be inspected.

Private technical preview

The evidence model is under active product development.

This site documents the direction. It is not currently an invitation to submit source code, estate data or production credentials.

Return to the platform model