Navi

What this project is

Navi turns an operational flowchart into a procedure change that a person can inspect before anyone accepts it. I worked on it as a software engineering intern at the UConn Tech Park Talent Incubator with HyAxiom. The project is being restarted around a smaller boundary: preserve what the source says, make interpretation visible, and keep generation separate from approval and execution.

The useful output is not a confident paragraph about a diagram. It is a reviewable chain from source evidence to a candidate artifact, with the decisions and checks along the way still visible.

The pipeline

source document
  -> parsed evidence
  -> canonical graph revision
  -> deterministic findings
  -> optional semantic proposal
  -> candidate artifact
  -> independent validation
  -> human review

The source document becomes an evidence graph with source identifiers, labels, geometry, reading order, warnings, and relationships. Corrections create new graph revisions instead of rewriting the original evidence. Semantic enrichment is optional and remains a proposal until a person accepts it.

The boundary that matters

Navi does not silently turn a diagram into a production action. A generated candidate is not a deployment. A local runtime pass is not proof for the target runtime. Model output is not source evidence.

Those rules shape the architecture. Parsing, graph contracts, findings, generation, validation, publication, and external systems have separate boundaries so a green check cannot quietly mean more than it proved.

Repository surfaces

• server/ owns parsing, graph contracts, validation, generation boundaries, and external adapters.
• workbench/ is the client and inspection surface. It is not the production authority.
• scripts/ contains bounded tooling and verification.
• docs/ contains the rewrite charter and current contracts.

The local workbench runs at http://localhost:5174 and the server runs at http://localhost:8788 in the documented development setup.

What I am measuring

A contributor should be able to answer these questions without reading the whole repository:

• Which source revision was read?
• Which nodes and edges were extracted deterministically?
• Which facts came from the source and which were inferred?
• What changed between graph revisions?
• Which artifact was generated?
• Which checks ran, and which did not?
• What remains uncertain?
• Who approved the candidate, and for which target?

That is the standard I want from tools that sit between messy operational documents and real work. The system should make uncertainty easier to find, not easier to hide.

Status

Navi is a working foundation for a controlled rewrite, not a claim that every adapter or target runtime is complete. The current implementation keeps the project honest by treating evidence, proposals, candidate artifacts, validation, and review as different things.