AI Initiative logoAI Initiative
Reading room / AI workflow research

Recursive Analysis Method v1

Recursive Analysis Method v1. A source-qualified account of the method, capability boundaries and required evidence.

Method specification
This is the retained source text, not a new validation of its claims. Numerical results and comparative claims require the accompanying source review before public reuse.

Read the connected case study or article →

Author not established in the source · Date not established

Provenance, authorship and editorial notes

Recursive Analysis Method v1

Id

method-recursive-analysis-v1

Project

AI workflow research

Source path

conduir-evolution/delivery/methods/RECURSIVE-ANALYSIS.v1.md

Source sha256

f4d987892a3248a5c4a3d3490d4a1b0b78d69df228d1e2e483eea725bf8a1848

Repo head

61278260a6a877769ef025356ecc5feb1d53f1b4

Date
Not recorded
Author
Not recorded
Document status

Method specification

Summary

Recursive Analysis Method v1. A source-qualified account of the method, capability boundaries and required evidence.

Evidence concerns
  • A preserved method or proposed capability is not a certified autonomous controller.
  • These documents retain their historical scope; no implementation or learning experiments were run for this website task.

Recursive Analysis Method v1

Status: CANDIDATE_STABLE_ENTRYPOINT

Stable invocation: $recursive-analysis <subject> or /recursive-analysis <subject>

Purpose

Use this method when an objective, product, capability, service family, architecture area, or
repository question must be analysed recursively rather than answered from a single file or one
agent's recollection.

The stable name replaces requests such as "run recursive V3" or "do V4 analysis." V3 and V4 remain
lineage terms:

Resolve current versions and trust state through METHOD-REGISTRY.v1.json before every run.

Default mode

The default is read-only analysis. It may create a report only when the user requests a durable
artifact. It grants no implementation, Jira, deployment, release, cleanup, procurement, or other
effect authority.

When the registry reports an unhealthy, stale, or unverified compiler, perform the sequence
manually and label the result MANUAL_RECURSIVE_ANALYSIS. Do not silently run an unhealthy
instrument or describe manual work as an executable V4 verdict.

Recursive sequence

1. Freeze the end goal, beneficiary, acceptance outcome, boundaries, non-goals, authority, and
exact analysis subject.
2. Describe the user or operator journey and the observable outcome at each meaningful step.
3. Derive the required capabilities without assuming the current implementation shape.
4. Inventory existing internal supply, external supply where relevant, contracts, ownership,
maturity, and exact evidence.
5. Resolve canonical component identities and separate current source, build, deployment, runtime,
and effectiveness facts.
6. Define the smallest executable composition test that would prove the required capabilities work
together for the journey.
7. Run only authorized, bounded observations; record instrument health and distinguish observed
failures from missing evidence.
8. Classify exact gaps as missing, wrong-shape, unsafe, unexposed, stale, contradicted, unproven, or
outside scope.
9. Produce role-neutral, dependency-ordered delivery packets with acceptance, authority, evidence,
rollback, and review requirements.
10. Report SOURCE, BUILT, DEPLOYED, and EFFECTIVE separately, and keep DEMO distinct from
same-digest APP evidence.
11. Define observation, rollback/reapply, evaluation, and learning so the result can improve a
successor rather than terminate at documentation or merge.
12. Require independent closure against a fresh source pin and preserve unresolved contradictions,
unknowns, and operator decisions.

Apply the same sequence recursively to a capability, work packet, or unresolved gap when its
internal complexity still prevents one owner, one coherent boundary, one evidence set, and one
independent review cycle.

Required report

Every result must include:

No-results, unavailable instruments, unsupported code, and stale evidence are valid report outcomes.
They must not be normalized into absence or PASS.

Governing references

Continue exploring