@thebackstoryis/engineering-with-ai 0.2.9

package/Docs/README.md

@@ -0,0 +1,50 @@
+# Engineering With AI guides
+
+Use these guides to get EWAI running, describe the work you want to do and take it through delivery. You don't need to read the whole library before starting.
+
+Conversation is the normal way to work with EWAI. Describe what you need in your AI host; the skills help it choose the workflow, ask for missing information, and run the supporting commands. Command examples are available when you want direct control, but you don't have to learn them first. Your choices and approvals still guide the work.
+
+For feature delivery, **`ewai-deliver` coordinates the full fourteen-stage workflow**, bringing in specialist skills as needed and resuming from the project's recorded state. You don't need to run each stage yourself. See the [delivery guide](developer-delivery-guide.md) for the stages and the decisions you'll be asked to make.
+
+## New to EWAI?
+
+1. [Install EWAI](operations/installation-updating-and-entitlements.md) and open it in your project folder.
+2. For existing code, follow [existing-project onboarding](existing-project-onboarding-guide.md). EWAI will offer Archaeology to reconstruct missing documentation; you can decline it.
+3. For a new project, follow [your first session](tutorials/first-session.md), then [your first delivery](tutorials/first-delivery.md).
+4. Read [how the fourteen stages fit together](explanation/delivery-workflow.md) when you want to understand the process. [Core concepts](explanation/core-concepts.md) explains the terms as you need them.
+
+The [Product Owner guide](product-owner-guide.md) covers deeper discovery and optional shared guidance. Bring the problem, examples and people who can help—not a finished technical specification.
+
+If you have a persona licence, [set it up before the analysis](operations/premium-personas-setup.md) you want it to support. Premium personas are optional.
+
+## What are you here to do?
+
+| Your task | Start here |
+| --- | --- |
+| Describe a feature or improve an existing idea | [Use Intent Studio](guided-intent-workspace-guide.md) |
+| Decide what to tackle next | [Use the Companion](context-aware-delivery-companion-user-guide.md) |
+| Implement an agreed change | [Developer delivery guide](developer-delivery-guide.md) |
+| Check that the result works for people | [Manual QA and acceptance](quality/manual-qa-and-acceptance.md) |
+
+If you're contributing without an engineering background, use the [non-technical team guide](adoption/non-technical-team-guide.md). For examples of the wider workflow, see [worked examples](examples/worked-examples.md).
+
+## Make the dashboard work for you
+
+[Choose which views you need](operations/dashboard-configuration.md). Portfolio, Team Hub, policy tools and the other advanced views are optional and start hidden. Showing a view doesn't configure the service behind it; hiding one doesn't remove checks your project requires.
+
+## Something isn't working?
+
+Start with [troubleshooting and recovery](operations/troubleshooting-and-recovery.md). For a problem that needs support, [prepare a private error report](error-reporting-guide.md) and review it before sharing.
+
+## Find a specialist guide
+
+The [complete guide catalogue](guide-catalogue.md) separates everyday use, engineering, team administration and EWAI maintenance. It includes the command reference, pack authoring, policy setup, integrations and verification notes. Choose what fits your task; the catalogue isn't a checklist.
+
+## A few boundaries worth knowing
+
+- **SPECS keeps the project's agreed knowledge.** Runtime indexes can be rebuilt; don't use a database edit to change an intent or approval.
+- **Personas help you think.** Their suggestions aren't evidence from real users or permission to build.
+- **Review and approval are separate.** Tests and a promising prototype don't replace Build approval or human acceptance.
+- **An installed pack isn't automatically suitable.** Review shared guidance before adopting it. Executable adapters need explicit registration and run with your operating-system permissions; they aren't OS-sandboxed.
+
+If you're changing EWAI itself, start in the [maintainer section](guide-catalogue.md#maintaining-ewai), not the application delivery instructions.

package/Docs/adoption/consultancy-and-multi-project-rollout.md

@@ -0,0 +1,135 @@
+# Consultancy and multi-project rollout guide
+
+Use this guide when one delivery organisation supports several clients, business units, or independent projects with EWAI.
+
+The engagement practices below are recommendations, not a required commercial service or a special consulting mode in EWAI. Teams can install and operate EWAI themselves. Where you operate it for a client, agree who owns the workspace, evidence and decisions before processing their material.
+
+## The isolation principle
+
+Several repositories can belong to one project; several clients shouldn't be treated as one project just because the same team supports them. Use separate project records and runtimes for independently owned work.
+
+When you need an overview, [Portfolio](../project-portfolio-orchestration-guide.md) compares configured local projects, [Team Hub](../team-hub-guide.md) shares explicitly published summaries and resources, and [Governed Rollout](../consultancy-network-rollout-control-plane-guide.md) compares adoption against agreed baselines. These views are optional; enable them through [Configuration](../operations/dashboard-configuration.md).
+
+Reusable methodology may cross project boundaries. Project truth, client evidence, decisions, credentials, and runtime state must not.
+
+Each project should resolve its own:
+
+- project root and configured SPECS root;
+- repositories and ownership;
+- Organisation Blueprint selection and receipt;
+- project personas and evidence;
+- validation providers and approval policy;
+- delivery state, dashboard, indexes, and logs;
+- data classification and AI-processing permission.
+
+Never carry a path, persona, source document, or delivery state from one client project into another merely because the same consultant or machine is involved.
+
+## Design three knowledge layers
+
+| Layer | Suitable content | Owner |
+| --- | --- | --- |
+| EWAI framework | Portable method, core skills, core personas, public schemas | EWAI maintainer |
+| Consultancy or organisation baseline | Reviewed delivery standards, organisation personas, approved Blueprint Packs | Practice or platform owner |
+| Project | Client purpose, users, evidence, constraints, decisions, project personas, delivery records | Client/project owner |
+
+Keep client-specific knowledge out of shared packs. Keep mandatory organisation rules in standards rather than hiding them inside personas.
+
+## Start every engagement with authority
+
+Agree:
+
+- who owns the project's SPECS and repository outputs;
+- what the consultancy may inspect, process, retain, and publish;
+- permitted AI hosts and data classifications;
+- approval and delegated-authority boundaries;
+- whether reusable learning may be generalised;
+- how secrets and client-identifying material are excluded;
+- handoff and deletion obligations at engagement end.
+
+Do not infer permission to reuse material from access alone.
+
+## Use Blueprint Packs as proposals
+
+A consultancy Blueprint can provide a high-quality starting point, but the client or project owner must review:
+
+- publisher and version;
+- required and optional modules;
+- applicable standards and their consequences;
+- persona templates and source ownership;
+- dependencies and compatibility;
+- governed starter receipts, with separate approval before adding starter files;
+- exact project destinations, receipt, and pin.
+
+The material becomes project-owned only after named approval. Record local exceptions and additions in the project, not by silently changing the shared pack for one client.
+
+## Create client-specific personas carefully
+
+Use project personas for client roles, workflows, vocabulary, and evidence-backed perspectives. Do not place them in a personal or shared organisation library.
+
+When extracting reusable learning:
+
+1. remove client identity and confidential facts;
+2. separate an observed project fact from a general practice hypothesis;
+3. obtain contractual and accountable approval for reuse;
+4. validate the generalisation with other evidence;
+5. publish it through the shared governance process as a new version.
+
+Managed premium personas remain licensed content and must not be republished in client packs or deliverables.
+
+## Operate separate runtimes
+
+Run check-in against the exact project:
+
+```bash
+ewai checkin --project /path/to/client-project --json
+```
+
+Use the returned dashboard URL for that project. Do not assume a single SQLite database or dashboard represents every engagement. Confirm the project title and root before acting on a handoff or approval.
+
+For multi-repository products, use one configured shared SPECS root and explicit repository roles. Do not create competing SPECS trees in each repository.
+
+## Offer review as a distinct service
+
+A consultancy can separate:
+
+- facilitation and intent quality;
+- engineering delivery;
+- standards and security review;
+- independent validation;
+- Manual QA support;
+- production-readiness or governance assessment.
+
+State independence honestly. The agent or team that produced work is not automatically an independent reviewer. Define evidence, scope, limitations, and decision authority for every assurance report.
+
+## Handoff a usable project
+
+At engagement end, provide:
+
+- canonical SPECS and repository history;
+- current intent and delivery states;
+- Blueprint receipts, pins, versions, and local changes;
+- project persona ownership and evidence;
+- standards, decisions, exceptions, and open risks;
+- validation and Manual QA evidence;
+- installation and runtime recovery steps;
+- support ownership and unresolved questions.
+
+Remove consultancy-only access and runtime material according to the agreed retention process without deleting client-owned evidence.
+
+## Multi-project checklist
+
+- [ ] Each project has an unambiguous root and SPECS owner.
+- [ ] Client data and personas remain project-local.
+- [ ] Shared packs contain only approved reusable material.
+- [ ] Premium content is not copied or republished.
+- [ ] Validation independence is stated accurately.
+- [ ] Project approval remains with an authorised person.
+- [ ] Runtime and dashboard actions target the correct project.
+- [ ] Handoff preserves durable truth and clarifies retention.
+
+## Related guides
+
+- [Organisation rollout guide](../organisation-rollout-guide.md)
+- [Internal Blueprint catalogue](../blueprints/internal-blueprint-catalogue.md)
+- [Organisation-specific personas](../personas/organisation-specific-personas.md)
+- [Human approval and assurance](../human-approval-and-assurance-guide.md)

package/Docs/adoption/non-technical-team-guide.md

@@ -0,0 +1,126 @@
+# Non-technical team guide
+
+Use this guide when you are contributing product, operations, risk, research, policy, or subject-matter knowledge without operating the EWAI command line yourself.
+
+## What EWAI needs from you
+
+You are not being asked to design the software. You are being asked to help make the intended outcome, real-world context, evidence, constraints, and acceptance decision explicit.
+
+Bring:
+
+- the problem as people experience it;
+- the outcome that would make the work worthwhile;
+- real users, stakeholders, and decision owners;
+- examples of the current process and its difficult cases;
+- known constraints and things that must not change;
+- evidence for important statements;
+- open questions and disagreements;
+- how you would recognise a useful and safe result.
+
+## Where to contribute
+
+Work with the project owner in the dashboard running on their computer, either together or in a screen-sharing session. Its local link won't open their project from another computer. The owner can also bring your written answers into the reviewed workflow; check the resulting draft before accepting it. Use **Guided Setup** to help describe a project, [Intent Studio](../guided-intent-workspace-guide.md) to shape one feature, or [Contributions](../guided-phase-evidence-drafting-guide.md) to add evidence to work already under way. Contributions is optional: enable it in **Configuration** first. You can also work through these questions in the EWAI conversation.
+
+## Before approving a draft
+
+Check that you can:
+
+- understand the topic being discussed;
+- ask for unfamiliar terms to be explained;
+- preserve a draft while the conversation develops;
+- see the active personas and why they're involved;
+- distinguish assumptions from evidence;
+- see what files or rules will be created;
+- read the complete Review before approving it;
+- see conflicts with existing project records before anything is written.
+
+If you cannot tell what a button will commit, do not approve it.
+
+## Understand personas
+
+Personas are prompts that bring different professional or user perspectives into the discussion. You may see a Product Owner, operator, accessibility, finance, architecture, or other lens become active as the topic changes.
+
+For each active persona, you should be able to see:
+
+- its name;
+- whether it is project, premium, personal, or core;
+- why it is relevant now;
+- which concerns it matched.
+
+Personas are advisory. They do not represent actual user research, stakeholder consent, legal advice, security certification, or approval. Correct them when their question does not fit the evidence.
+
+## Describe evidence, not only conclusions
+
+Instead of:
+
+> Users need a dashboard.
+
+Try:
+
+> Three operations managers currently combine two reports each morning to identify delayed cases. They need to see exceptions before the 9:30 review. The dashboard is one proposed solution.
+
+This preserves the human need if the implementation changes.
+
+## Mark the status of statements
+
+Use clear language:
+
+- **Observed:** supported by direct evidence.
+- **Proposed:** an option for consideration.
+- **Agreed:** participants align, but formal authority may still be needed.
+- **Decided:** an authorised person made the choice.
+- **Implemented:** observable in the current system.
+- **Unknown:** evidence is missing.
+- **Contradicted:** sources disagree.
+- **Superseded:** a later decision replaced it.
+
+Do not let a polished summary turn a proposal into a decision.
+
+## Review an organisation baseline
+
+An Organisation Blueprint Pack may propose standards and personas that your organisation normally uses. During Review, ask:
+
+- Does this baseline actually apply to this project?
+- Which parts are mandatory and which are optional?
+- What will be written into the project?
+- What evidence and approval will be retained?
+- Is any project-specific exception needed?
+
+The Blueprint publisher provides the baseline. The project owner remains accountable for adopting it.
+
+## Give approval carefully
+
+Approval should show:
+
+- the complete proposed outcome;
+- exact consequences and destinations;
+- evidence, assumptions, exclusions, and conflicts;
+- the version or digest of reusable content;
+- the named person approving;
+- what future changes would require another review.
+
+Selection, preview, and approval are different actions.
+
+## Participate in Manual QA
+
+You may be the best person to test whether a delivered workflow is useful. Ask for a walkthrough that states the environment, starting point, actions, expected results, and known limitations.
+
+Record what actually happened. A failed step is valuable evidence; do not smooth it into a pass. Manual QA acceptance does not itself deploy the change.
+
+## Questions you should always be able to ask
+
+- Why are we doing this?
+- Who supplied this information?
+- Which persona is active, and why?
+- Is this a fact, proposal, decision, or inference?
+- What changes if I approve?
+- What remains unknown or untested?
+- Who owns the risk or follow-up?
+- Can we reverse this safely?
+
+## Related guides
+
+- [Product Owner guide](../product-owner-guide.md)
+- [Guided Discovery facilitator guide](../guided-discovery-facilitator-guide.md)
+- [Manual QA and acceptance](../quality/manual-qa-and-acceptance.md)
+- [Worked examples](../examples/worked-examples.md)

package/Docs/archaeology-technology-and-hosting-discovery.md

@@ -0,0 +1,212 @@
+# Archaeology technology and hosting discovery
+
+Use this capability during Archaeology to turn repository signals and accountable human answers into a governed view of the technology actually used and where it actually runs.
+
+It is designed for inherited systems, poorly documented services, mixed estates and repositories whose deployment files no longer reliably describe production. It supports cloud, on-premises, SaaS, PaaS, IaaS, managed-service and hybrid operating models.
+
+Ask EWAI: “During Archaeology, help me establish which technologies this project uses and where it actually runs.” EWAI prepares a briefing from the repository evidence and asks you to confirm the real operating environment. You review misleading signals, supply evidence and identify what remains unknown. Configuration files alone don't establish what's live.
+
+The command and JSON reference below is for a technical owner who wants to inspect or record the profile directly. In the guided conversation, EWAI prepares the bundle and answer template with you. If you don't own the hosting information, involve the platform or service owner rather than guessing.
+
+
+<!-- editorial: contents -->
+## On this page
+
+- [What it produces](#what-it-produces)
+- [Evidence language](#evidence-language)
+- [Before you begin](#before-you-begin)
+- [Repository topologies](#repository-topologies)
+- [Common signals and pack extensions](#common-signals-and-pack-extensions)
+- [Prepare the owner briefing](#prepare-the-owner-briefing)
+- [Complete the answer template](#complete-the-answer-template)
+- [Record the reviewed profile](#record-the-reviewed-profile)
+- [Check status and handle drift](#check-status-and-handle-drift)
+- [Human review checklist](#human-review-checklist)
+- [Required assurance notice](#required-assurance-notice)
+
+## What it produces
+
+The workflow adds five files to the selected Archaeology evidence bundle:
+
+| File | Purpose |
+| --- | --- |
+| `technology-hosting-brief.json` | Machine-readable Source Map observations, active personas, questions, limitations and preparation digest. |
+| `technology-hosting-brief.md` | Human-readable briefing for the owner conversation. |
+| `technology-hosting-answers.template.json` | Governed input template for owner declarations and confirmations. |
+| `technology-hosting-profile.json` | Attributed reviewed profile preserving observations, answers, contradictions and unresolved questions. |
+| `technology-hosting-profile.md` | Human-readable profile and evidence status. |
+
+The workflow does not automatically change the canonical stack strategy, choose a hosting provider, install a technology pack, inspect a live cloud tenant, deploy anything or certify security. A reviewed profile can later support an explicit Archaeology curation decision.
+
+## Evidence language
+
+The profile deliberately separates three kinds of statement:
+
+- `repository-observed`: the Repository Source Map found a file or pack profile that suggests a technology or deployment surface;
+- `owner-declared`: a person supplied an answer but did not mark that individual answer as confirmed;
+- `human-confirmed`: a person explicitly marked that individual answer as confirmed and supplied the relevant evidence references.
+
+A reviewer name does not confirm every answer. Confirmation is per technology, hosting field, location and environment.
+
+Configuration is never proof of current runtime state. A Terraform file may describe an old experiment. A Salesforce project can be present while a different tenant is live. A CI workflow may no longer be the approved production release route. Keep those signals and record their disposition as `active`, `inactive`, `contradicted` or `uncertain`.
+
+## Before you begin
+
+This isn't a standalone scan for an empty folder. Accept the optional investigation through [existing-project onboarding](existing-project-onboarding-guide.md#choose-whether-to-run-archaeology), then use the bundle that `ewai-archaeology` prepares. The dated bundle path below is an example: replace it throughout with your actual bundle. Don't create an empty directory and expect it to satisfy the persona-routing prerequisite.
+
+1. Complete EWAI initialization and explain the project's purpose.
+2. Accept Archaeology; EWAI prepares or selects its bundle under the configured `SPECS/3.Evidence/archaeology/` root.
+3. Review EWAI's proposed persona perspectives. The agreed selection is recorded in `persona-routing.yaml`.
+4. Put the relevant repositories and extracted platform source in scope, then have EWAI refresh the Repository Source Map. The direct inspection commands are:
+
+```bash
+ewai index refresh --project .
+ewai index freshness --project . --json
+ewai archaeology validate-personas \
+  SPECS/3.Evidence/archaeology/2026-08-23-system-baseline \
+  --project . --json
+```
+
+Preparation refuses a stale Source Map. It does not silently refresh the index because refreshing and analysing repository evidence is a distinct operation the operator should be able to see.
+
+## Repository topologies
+
+Technology and hosting discovery uses the repositories already configured in `SPECS/pipeline.yaml`.
+
+### Single repository
+
+Use one configured application repository. Signals and evidence paths are labelled with that repository name.
+
+### Monorepo
+
+Configure the monorepo once. The Source Map retains paths for each service, application, infrastructure area and package, so the owner can confirm different runtimes or deployment paths by environment.
+
+### Folder containing repository subfolders
+
+Configure each repository subfolder as a named repository under the shared SPECS contract. The discovery profile retains the repository name on every observation instead of flattening the estate into one inferred stack.
+
+This is particularly important when application, infrastructure, CRM and low-code exports live in separate repositories.
+
+## Common signals and pack extensions
+
+EWAI recognises common repository signals for:
+
+- Node.js, Bun, PHP, Python, Go, Rust, Ruby, JVM and .NET projects;
+- Nuxt, Next.js, Angular, Vite and Prisma configuration;
+- package managers and lockfiles;
+- Docker, Docker Compose, Kubernetes and Helm;
+- Terraform and Azure Bicep;
+- GitHub Actions, GitLab CI/CD, Azure Pipelines and Jenkins;
+- Azure, AWS, Google Cloud, Vercel, Netlify, Fly.io, Render, Railway and Heroku-compatible descriptors;
+- OpenAPI and GraphQL contracts;
+- Microsoft Power Platform and Salesforce project exports.
+
+This catalogue is not a closed list. Installed technology, stack, Organisation Blueprint and project Source Map profiles can match additional file types. Those matches appear as pack-provided `source-map-profile` observations carrying the exact profile ID and analyser metadata. EWAI does not turn that identifier into a more specific claim unless the repository or a human supplies the evidence.
+
+### Power Platform and Salesforce exports
+
+Power Apps and Salesforce can export application or project configuration as archives. Export the material using the platform's supported process, extract the archive into a repository or configured repository subfolder, then refresh the Source Map before preparing discovery.
+
+EWAI does not extract ZIP or `.msapp` archives for you. The extracted folder is evidence supplied by the operator; it is not proof of the tenant, environment, region or live release state. See [Power Platform and Salesforce export analysis](platform-export-analysis-guide.md) for the extraction and indexing boundary.
+
+## Prepare the owner briefing
+
+```bash
+ewai archaeology prepare-technology-hosting \
+  SPECS/3.Evidence/archaeology/2026-08-23-system-baseline \
+  --project . --json
+```
+
+Preparation:
+
+- reads only safe Repository Source Map projections;
+- detects built-in and pack-provided signals across every configured repository;
+- loads the approved persona-routing inventory;
+- engages the core Archaeologist and SPECS Knowledge Curator plus relevant confirmed premium, personal and project personas;
+- records exactly which personas are active and why;
+- produces questions covering actual technology, provider, platform/service, locations, environments, deployment model, operating model, data residency, release route, inactive signals, contradictions and unresolved questions.
+
+Premium personas improve the lenses available when installed and selected. They are not required for the standard workflow, are never downloaded by this command and cannot replace evidence or accountable confirmation. Project-local personas are valuable for organisation-specific hosting, architecture, operations and release responsibilities.
+
+## Complete the answer template
+
+In the guided conversation, answer the briefing questions and check EWAI's proposed record. For direct editing, open `technology-hosting-answers.template.json` in the selected bundle and change its answers, not the generated brief. Preserve `schema` and `preparedDigest`. Confirm each answer only if you have the responsibility and evidence to do so; otherwise ask the appropriate owner.
+
+For example, find an observation in `technology-hosting-brief.json`, copy its actual `ATH-OBS-…` ID into the related answer's `observationRefs`, and record whether the responsible person confirmed it. `ATH-OBS-1234567890` below is illustrative, not an ID you can submit unchanged. If no observation supports a declaration, don't manufacture one.
+
+Each answer supports:
+
+```json
+{
+  "value": "Microsoft Azure",
+  "confirmed": true,
+  "observationRefs": ["ATH-OBS-1234567890"],
+  "evidence": ["Platform owner confirmation", "Production service inventory"],
+  "notes": "Primary production provider"
+}
+```
+
+Technology items use `category`, `name` and optional `version` alongside the same confirmation and evidence fields. Environments additionally record provider, platform/service, location, deployment model and operating model.
+
+Use `unknown` when the answer is not established. Record the owner of the missing answer in `unresolvedQuestions`. Do not infer a provider, region or data-residency statement from repository configuration.
+
+Supported deployment-model values are:
+
+`cloud`, `on-premises`, `saas`, `paas`, `iaas`, `managed-service`, `hybrid`, `other`, `unknown`.
+
+Supported operating-model values are:
+
+`self-managed`, `provider-managed`, `shared`, `third-party-managed`, `hybrid`, `unknown`.
+
+Use `observationReviews` to mark each misleading or uncertain repository signal. Preserve contradictions explicitly rather than choosing one source and deleting the other.
+
+## Record the reviewed profile
+
+```bash
+ewai archaeology record-technology-hosting \
+  SPECS/3.Evidence/archaeology/2026-08-23-system-baseline \
+  --input SPECS/3.Evidence/archaeology/2026-08-23-system-baseline/technology-hosting-answers.template.json \
+  --reviewed-by "Platform owner" \
+  --project . --json
+```
+
+The input file must resolve inside the project. Recording validates the preparation digest, every observation reference, deployment and operating vocabularies, reviewer identity and the no-overwrite boundary. The two profile files are written as one recoverable file transaction.
+
+After recording, open both `technology-hosting-profile.md` and `.json` in that bundle and check `technology-hosting-status` reports `recorded`. You should see repository observations and owner answers kept separately, including unresolved questions.
+
+Recording does not promote the result into canonical strategy. Use the normal Archaeology review and curation workflow when the profile is ready to support proposed SPECS records.
+
+## Check status and handle drift
+
+```bash
+ewai archaeology technology-hosting-status \
+  SPECS/3.Evidence/archaeology/2026-08-23-system-baseline \
+  --project . --json
+```
+
+Status is one of:
+
+- `missing`: no preparation exists;
+- `prepared`: the briefing exists and awaits a recorded profile;
+- `recorded`: the profile matches the preparation and Source Map run;
+- `stale`: the Source Map changed, became stale, or the profile no longer matches its preparation;
+- `invalid`: a stored artefact cannot be read or validated.
+
+The status check ignores only this capability's five generated bundle files. Any unrelated indexed file addition, change or deletion makes the result stale.
+
+Preparation does not overwrite existing artefacts unless `--force` is explicitly used. A forced re-preparation never overwrites an existing reviewed profile; instead the old profile becomes stale against the new preparation digest. Preserve the previous bundle when historical traceability matters, and normally create a new dated Archaeology bundle for a new baseline.
+
+## Human review checklist
+
+- Every material runtime, framework, data store, integration and infrastructure component is either recorded or explicitly unknown.
+- Provider, platform/service, location, environment, deployment model and operating model are answered separately.
+- Data storage, processing, backup and replication locations have an accountable confirmation owner.
+- The real release route, approval points and rollback route are recorded.
+- Historical and inactive repository signals retain a disposition and explanation.
+- Contradictions and unresolved questions remain visible.
+- Active personas are visible, relevant and within the approved routing decision.
+- No persona or repository signal is presented as stakeholder acceptance, security approval or business truth.
+
+## Required assurance notice
+
+Security validation is evidence, not certification or proof that this system is secure. Tools can miss vulnerabilities and produce false positives. A qualified human must review the scope, findings, limitations and residual risk before release.