RebuildReady Output Governance

Inputs that shape every package

• Industry. Real estate, commercial lending, WordPress e-commerce, SaaS, internal tool, or generic.
• Application type. Legacy codebase, WordPress plugin, WordPress site, static site, SPA, backend service, data pipeline, or unknown.
• Available evidence. Source code (snippet, partial tree, full tree), dependency manifest, database schema, sample data, runtime logs, observability metrics, API contracts, tests, infrastructure config, environment variables, third-party service inventory, third-party terms review, business rules, user role matrix, modernization goal, target environment, and private-use confirmation.
• Deployment environment. Static shared hosting, cPanel/VPS, container runtime, serverless/edge, managed PaaS, or unspecified.
• Intended outcome. Risk assessment, modernization blueprint, reproducible package, portability plan, or compliance gap review.

What the governance engine decides

• Which inputs are required for the requested outcome.
• Which analyses are performed based on the evidence actually supplied.
• Which output modules apply to this outcome.
• Which deliverables can be completed from the evidence.
• Which deliverables must remain provisional.
• Which findings require human confirmation before being trusted.
• Which deliverables cannot honestly be produced from what was provided.

Deliverable states

• Complete. All evidence required for this deliverable was supplied.
• Provisional. Some required evidence was missing; the deliverable is directional only.
• Needs human confirmation. Producible mechanically, but ownership / business context must be human-confirmed before use.
• Cannot be produced. Core evidence is absent; RebuildReady declines to fabricate the output.

How gaps are documented

Every missing piece of required evidence is reported as an explicit gap with three parts:

• Missing evidence. The named input that was not supplied.
• Operational consequence. What downstream claims cannot honestly be made without it.
• Requirements to resolve. The concrete steps needed to close the gap.

Where this shows up today

The private Legacy Code Risk Scan Report renders a RebuildReady output governance section that lists required inputs, performed analyses, applicable output modules, deliverable states, and documented gaps derived from the actual scan context. Additional workflows (modernization blueprint, reproducible package, portability plan, compliance gap review) use the same engine so their reports remain consistent and evidence-honest.

What this is not

• Not a compliance audit or legal opinion.
• Not a substitute for human review of business rules, security posture, or licensing.
• Not a guarantee that a provisional deliverable will become complete without additional evidence.