Conversational CodingA Backstory project Install the harness →
Menu

Understand the system before AI starts changing it.

An inherited codebase is full of evidence, but it isn’t a trustworthy statement of intent. Engineering With AI maps what exists, finds what’s missing, brings the contradictions to a person and builds the project knowledge the next piece of work needs.

One system. Seven questions.

ProductArchitectureDataSecurityDeliveryGovernanceOperations

Each area can be investigated at a bounded, standard or deep level. The depth is chosen from evidence and confirmed by a named person, not inferred from repository size.

The repository can tell you what happens. It can’t tell you what was meant to happen.

Temporary fixes look permanent once the person who made them has left.

Documentation drifts. Tests prove one boundary and say nothing about another. Configuration names a service without explaining who owns it. A batch process may be critical, obsolete or simply the least bad option somebody had on a Friday afternoon.

This part of the harness keeps those distinctions visible. It gives strong repository evidence its proper weight without promoting every observable behaviour into a requirement.

A map, an investigation and a reviewed project record.

01

Archaeology reconstructs the missing knowledge

Bounded passes examine purpose, journeys, architecture, data, decisions, standards, security, operations and history. Findings stay linked to source evidence, and missing or conflicting material remains explicit.

See the complete Archaeology journey →

02

Repository Source Map

Every non-excluded file is inventoried. Supported code receives deeper structural analysis, while sensitive, oversized, unsupported and failed surfaces remain visible instead of disappearing from the coverage story.

03

Reproducible evidence depth

Architecture, data, security, product, delivery, governance and operations receive independent depth recommendations, stable gap identities and a named review that can be compared later.

04

Technology and hosting profile

Repository observations and owner-confirmed facts are kept separate while the system records environments, deployment topology, ownership, recovery and the limits of what the code can prove.

05

Platform export analysis

Already-extracted Power Platform and Salesforce source can be examined through bounded metadata analysers, with partial coverage and unsupported material stated plainly.

06

Relevant specialist lenses

Product, architecture, operations, security, data and assurance personas can challenge different parts of the investigation. Their questions improve coverage; they don’t become evidence about real users or replace the owner who resolves a disagreement.

Illustrative investigation

A nightly export exists. That doesn’t tell you whether anyone still needs it.

The useful result isn’t a paragraph confidently explaining the job. It’s a record of what’s known, what’s inferred and who can settle the question.

Separate evidence from assumptions before changing the export.
What we foundWhat it tells usWhat happens next
Observed
A scheduled job writes a CSV file every night.
The implementation exists. Production use is not yet confirmed.Check the running environment and job history.
Conflicting
An old runbook calls it a finance feed; a comment calls it temporary.
Neither description should silently become the requirement.Ask the finance owner what consumes it.
Unknown
No current owner or recovery procedure is recorded.
Deleting or changing the job could affect a process we haven’t identified.Record the unanswered question before planning a change.

Archaeology follows this discipline through the inventory, investigation and owner review. Only reviewed knowledge moves into the project’s canonical SPECS. See how the investigation works →

The questions this route is built to answer.

What can the repository prove?

See analysed files, inventory-only surfaces, relationships, entry points and explicit failures rather than a confident summary with invisible blind spots.

Where does intended purpose disagree with current behaviour?

Present, Partial, Missing, Conflicting and Unknown findings make that disagreement reviewable before it becomes a bad plan.

What documentation will we have afterwards?

Reviewed project purpose, journeys, architecture, data, constraints, decisions, standards, operations and open questions move into predictable project-local homes.

Can we trust it enough to build?

Trust comes from traceable evidence and named review. Archaeology prepares the starting point; it doesn’t grant Build, security, Manual QA or release approval.

Know what you have. Then decide what should change.

Archaeology gives an old project a reviewed memory. The rest of the harness turns that understanding into bounded intent, plans, delivery and evidence.