Enterprise Architecture Review Assistant

Comprehensive Alpha Intake, Engineering Orientation, Platform Alignment, Resourcing, Value Blueprint, Agent-Ready Repo Bootstrap, Copilot Alignment, Manual Harness, Navigation-Restored HTML, and Controlled Build-Preparation Handoff v1.14.1

Purpose

This package explains what we are trying to build, why it matters, how it should be governed, what needs to be defined before engineering starts, how the emerging enterprise AI platform patterns should influence the delivery path, and what roles, effort, and run economics must be understood before this moves from idea to build.

It is written for four audiences at once:

1. David and the EA/governance team, who own the review judgment, standards, criteria, and final decision model.
2. Tony and product/architecture collaborators, who need to convert the idea into a buildable product shape.
3. Engineering or platform teams, including Rob C's team or equivalent implementation resources, who may help wire the capability into approved platforms and systems.
4. Future submitters, because this package should become the alpha example of what good AI or agentic intake should look like before anyone starts building.

The short version: this is not a proposal to replace architects with an agent, and it is not a proposal to build a clever demo that cannot be sustained. It is a proposal to build an internally owned architecture intelligence layer that helps architects do first-pass review faster, more consistently, and with stronger evidence. The agent is only the interface and assistance layer. The hard part is the review brain.

Executive thesis

The central recommendation is direct: own the brain, wire the interface.

The enterprise should internally own the product intent, review criteria, standards interpretation, source authority, data classification, reference patterns, semantic/control model, exception logic, evidence model, prioritization rules, and decision memory. A supplier or technical team can help with implementation wiring, workflow, integrations, Copilot/Copilot Studio mechanics, Azure/AWS orchestration, telemetry, and deployment plumbing. But the architecture intelligence layer should not be outsourced.

That distinction matters because the value of this product is not a chatbot, portal, or model call. The value is a governed, versioned, reusable architecture review capability that can explain why a submission passes, fails, needs more evidence, requires escalation, or should be routed to a different platform or governance path.

A vendor can build a portal. A vendor can configure an agent. A vendor can wire APIs. A vendor cannot responsibly define how this enterprise judges architecture fitness, risk, source authority, platform alignment, GxP posture, or exception acceptability. If we hand that layer away, we will rent back our own architecture judgment through maintenance fees and change orders, which is apparently how civilization chose to monetize avoidable dependency.

1. The problem we are solving

Architecture review demand is increasing, especially for AI, GenAI, cloud, SaaS, integration-heavy, and emerging technology submissions. The architecture team is expected to process more reviews without a proportional increase in headcount. The current operating model depends heavily on manual review, scattered standards, inconsistent artifacts, and the institutional memory of individual architects.

The business problem is not simply that reviews take too long. The deeper problem is that the enterprise lacks a scalable, consistent, explainable, and reusable way to evaluate architecture submissions against current standards, approved patterns, data requirements, security expectations, platform constraints, existing capabilities, and prior decisions.

Today, a high-quality review often requires an architect to know where standards live, which version applies, what technologies are approved or restricted, whether an existing capability already solves the problem, how similar decisions were handled before, which governance route applies, and whether an exception is justified. Much of that knowledge is distributed across people, repositories, portals, decks, tools, and memory. That does not scale.

Current pain points

What a bad review can cause

A weak or inconsistent review can approve non-standard technology, miss a duplicative capability, allow an unsupported or non-scalable pattern, overlook security or data issues, accept an exception without clear rationale, or create a decision that cannot be defended later. In a regulated healthcare, pharma, and medical device environment, those failures are not academic. Some may become operational, compliance, audit, quality, or patient-impacting problems.

This is why the assistant must improve rigor, not merely speed.

2. The vision

The vision is an Enterprise Architecture Review Assistant that helps architects perform first-pass evaluation of architecture submissions using a governed, evidence-backed, internally owned review model.

The assistant should be able to:

1. Access or receive submitted architecture artifacts.
2. Extract solution intent, business context, technologies, integrations, data flows, security model, operating model, and missing evidence.
3. Classify the submission by domain, risk, data sensitivity, GxP potential, business impact, platform path, and governance route.
4. Determine whether AI is actually appropriate, or whether the use case is better served by deterministic workflow, rules, dashboarding, search, or a data product.
5. Evaluate the submission against approved standards, reference patterns, tool catalogs, control libraries, and architecture principles.
6. Generate standardized review outputs: summary, scorecard, findings, evidence, missing information, risks, recommendations, and decision posture.
7. Keep final approval with human architects.
8. Capture final decision rationale and exceptions as reusable institutional memory.

The long-term capability should make reviews faster, more consistent, more explainable, and more reusable. It should also become a pattern for how future AI/agentic use cases enter architecture review.

The product philosophy

3. What we are building

We are building a decision-support capability for enterprise architecture review. It has three primary layers.

3.1 Intake and governance layer

This layer clarifies the request before review begins. It should determine what the submission is, who owns it, what business outcome it supports, whether it is an AI use case, what governance path applies, what platform route is likely, and what evidence is required before a meaningful review can occur.

This is where the future assistant should ask the questions we are asking ourselves now: What problem are we solving? Why does this need AI? What data is required? What sources are authoritative? What evidence proves the architecture is ready? What review path applies?

3.2 Architecture intelligence layer

This is the internal asset. It contains source authority, standards, review criteria, control definitions, reference patterns, anti-patterns, approved technologies, data classification, evidence requirements, exception logic, prior decisions, and review-output schemas.

This layer should be versioned, governed, auditable, and reusable. It should not live as undocumented prompt text. It should be represented through structured artifacts such as JSON, YAML, Markdown, schemas, control libraries, and reviewer guidance.

3.3 Experience and implementation layer

This is the interface and runtime layer. It may involve Copilot, Copilot Studio, Teams, SharePoint, the AI Governance Portal, Azure services, AWS services, APIs, MCP, A2A, REST, event patterns, observability, and workflow automation.

This layer can change over time. The architecture intelligence layer should survive changes in UI, model provider, cloud runtime, licensing, and token economics.

4. What we are not building yet

The first version should not become a full enterprise governance platform. It should not automate final approval. It should not replace the Architecture Review Board. It should not become the single system for legal, privacy, security, quality, procurement, and architecture workflows. It should not create a duplicate intake portal if an existing AI Governance Portal or submission system already serves as the system of record.

The first version should prove the disciplined review pattern:

• Can we define the minimum review criteria?
• Can we classify submissions correctly?
• Can we identify missing evidence?
• Can we evaluate against trusted sources and reference patterns?
• Can we produce useful findings that architects trust?
• Can we capture final decisions for reuse?

If those are not true, adding a nicer interface just gives us a more attractive way to be wrong.

5. Why this should be the golden alpha intake model

This use case should model the behavior we eventually expect from other AI and agentic submissions. It is both a product concept and a process example.

Before future teams request or build AI-enabled solutions, they should be able to explain:

• What problem they are solving.
• Who has the problem.
• What happens if nothing changes.
• Why AI is appropriate.
• What deterministic alternatives were considered.
• What data is required.
• Who owns the data.
• What is canonical versus reference-only.
• What governance review is required.
• What platform path is preferred.
• What security, privacy, GxP, quality, audit, or business-risk obligations apply.
• What output must be produced.
• Who owns sustainment.
• What it costs to build, run, improve, and govern.
• Whether the value justifies the engineering and operating cost.

This package should become the first working example because it exposes the truth that many AI projects try to avoid: the hard part is usually not model access. The hard part is clarifying intent, governing data, defining criteria, mapping source authority, managing evidence, and deciding who owns the decision.

6. Methodology: from idea to build-ready

The methodology should balance upfront discipline with practical delivery. We need enough definition to avoid building the wrong thing, but not so much documentation that the project suffocates in its own ceremony.

Stage 1: Intent clarification

Define the problem, target users, first review type, value hypothesis, non-goals, and decision boundaries.

Required outputs:

• Problem statement
• Vision statement
• First use case
• Target users
• Value hypothesis
• Non-goals
• Success and failure criteria

Stage 2: Governance routing

Classify the use case across business function, enterprise platform governance, security, privacy, quality, GxP potential, and AI governance.

Required outputs:

• Governance route
• Required approvers
• Fast-path versus standard-review eligibility
• Security and privacy triggers
• GxP and quality triggers
• Auditability requirements

Stage 3: AI appropriateness gate

Determine whether the problem actually needs generative AI or agentic AI.

Required outputs:

• AI appropriateness statement
• Deterministic alternative assessment
• Human-in-the-loop requirement
• Decision impact classification
• Required explainability level

Stage 4: Data and source authority model

Identify all relevant sources, classify them, determine authority, and define what can be used as evidence.

Required outputs:

• Source inventory
• Source authority map
• Data classification model
• Evidence model
• Access model
• Retention model
• Refresh model

Stage 5: Review criteria and control design

Turn architecture principles into reviewable controls. This is where vague principles become operational checks.

Required outputs:

• Review rubric
• Control library
• Reference pattern library
• Anti-pattern library
• Technology catalog
• Exception rules
• Severity model

Stage 6: Platform-fit routing

Map the use case to the right implementation path.

Required outputs:

• Front door recommendation
• Runtime recommendation
• Integration pattern
• Model/tool access path
• Plan B for licensing or tokenomics changes
• Supplier role boundary

Stage 7: Resourcing and value gate

Before build, define the minimum team, delivery path, expected effort, technology cost exposure, run economics, and value hypothesis. This is not procurement theatre. It is a reality check. A use case that cannot explain who will build it, who will run it, what it costs, and why it is worth doing should not be approved just because someone used the word agent.

Required outputs:

• Delivery role map
• Internal versus augmented skills plan
• Rough order-of-magnitude effort estimate
• Build cost estimate
• Run cost and tokenomics model
• Sustainment owner
• Value hypothesis and stop criteria

Stage 8: Pilot gate

Before build, define the pilot set and evaluation method.

Required outputs:

• Pilot submissions
• Gold-standard human review baseline
• Accuracy and usefulness metrics
• Override tracking
• Cycle-time baseline
• Pilot success criteria

7. How an engineer should read this package

This section is for implementation teams who have not lived through the discovery conversations.

An engineer should not read this package as a final architecture design. It is a build-orientation package. It explains the product intent, source materials, configuration assets, likely platform paths, and open decisions that must be resolved before detailed design.

Recommended reading order

1. Read the problem statement and vision.
2. Read the alpha intake methodology.
3. Read the data architecture and source authority sections.
4. Review the platform-fit routing model.
5. Review the configuration and data asset map.
6. Review the engineering build flow.
7. Treat the source library as provenance and evidence, not as official policy unless validated.
8. Treat JSON/YAML/schema/control files as seed configuration, not final enterprise standards.

Engineering north star

Build an assistive EA review system that ingests architecture submissions, extracts structured facts, evaluates them against internally owned controls and source-authority rules, produces evidence-backed findings, and routes final decisions to human architects.

What engineers should not do

• Do not hard-code review criteria into prompts.
• Do not make the model the final approver.
• Do not build a duplicate intake portal unless integration is blocked.
• Do not treat company-agnostic templates as official policy without validation.
• Do not make source authority subjective or prompt-driven.
• Do not bury critical review logic in a black-box model response.

8. Engineering build orientation

The engineering model should separate configuration, deterministic logic, AI assistance, workflow, and human review.

8.1 Conceptual component model

8.2 Minimum viable build flow

1. Select a pilot review type.
2. Load a controlled source package.
3. Receive or access submitted architecture artifacts.
4. Inventory the package and detect missing expected artifacts.
5. Extract structured submission facts.
6. Apply classification and source authority rules.
7. Evaluate against the initial control library.
8. Generate evidence-backed findings.
9. Route findings to an architect for review.
10. Capture accept/reject/edit/override actions.
11. Store the final decision record.
12. Feed approved decisions and exceptions into the decision memory layer.

8.3 Deterministic versus AI-assisted responsibilities

9. Configuration and data asset map

The “brain” of the system should be a versioned configuration and data layer, not a pile of prompt text.

Configuration principle

Anything that changes because a standard changes should not require application code changes. Standards, controls, source status, platform routing, severity, and evidence requirements should be governed configuration wherever feasible.

10. Enterprise platform alignment

The newly supplied enterprise stack inputs materially improve the package. They show a platform posture that appears to favor Microsoft for front-door/orchestration experiences, AWS as an approved runtime and infrastructure pattern, and open interoperability through MCP, A2A, REST, and event streaming.

These inputs are valuable, but several are company-agnostic templates or model-distilled artifacts. They should be treated as platform intelligence inputs until confirmed by platform owners.

10.1 Microsoft front door

The user experience should likely begin where users already work: Copilot, Teams, SharePoint, or Copilot Studio. For early piloting, Copilot/Agent Builder may help test prompts and outputs. For a governed team assistant, Copilot Studio is more realistic.

10.2 Azure service path

Azure may be useful for AI Foundry, Azure OpenAI, AI Search, Semantic Kernel, API Management, Key Vault, Purview, Logic Apps, Durable Functions, Power Automate, Graph, Log Analytics, and integration into the Microsoft collaboration ecosystem.

10.3 AWS runtime path

If enterprise platform leadership prefers AWS for deeper runtime, orchestration, or Bedrock-native patterns, the product should remain compatible with AWS services such as Bedrock, AgentCore, Step Functions, EventBridge, Lambda, S3, KMS, CloudWatch, and related runtime services.

10.4 Interoperability patterns

MCP, A2A, REST, and event streaming should be treated as candidate integration patterns. They matter because the assistant may eventually need to interact with source systems, registries, enterprise agents, review workflows, and decision stores.

10.5 Plan B

The architecture should avoid tying the intelligence layer to one vendor, one front door, one model, or one licensing model. Copilot token economics may be favorable today. That is not a permanent architecture guarantee. The control library, source authority map, schemas, and decision memory should be portable.

10.6 Copilot Premium and Studio governance alignment

The internal AI Platform team context materially validates the staged path already used by this package. Copilot is the broad enterprise front door, but the governance model becomes stricter as agent audience, data access, integration depth, and operational dependency increase.

The relevant platform signal is not merely that Copilot exists. The relevant signal is that the enterprise already distinguishes lightweight individual experimentation from team, function/sector, and enterprise agent patterns. That means this Enterprise Architecture Review Assistant should not leap from a strong package to broad deployment. It should first prove the evidence loop under the correct tier, with data handling and publishing boundaries explicit.

Copilot maturity roadmap signal

Governance tier interpretation

The governance break point is important. Below the Team/Function boundary, Copilot Premium-approved data may be sufficient. At Function/Sector or Enterprise scope, data must be approved for the use case, formal approval is required, enterprise support becomes mandatory, and full SDLC applies.

Implication for this Enterprise Architecture Review Assistant

This package remains aligned with the platform model:

• A manual harness or individual experimentation may be used to test the framework against non-sensitive, approved data.
• A team review assistant or shared agent should be treated as a governed request, not casual experimentation.
• Function/Sector or Enterprise use requires full SDLC, approved data handling, enterprise support, Copilot Service team publishing, and validated telemetry.
• Copilot Studio or Azure AI Foundry become relevant only after the evidence loop, source authority, data boundaries, and human review workflow are proven.
• The control library, source authority map, schemas, and decision memory remain internal assets regardless of the front door.

The platform team context therefore increases confidence in the staged delivery model. It does not remove the pilot blockers. The blockers become more defensible, which is annoying only if someone hoped governance would politely disappear.

11. Platform-fit routing model

The implementation path should follow the use case profile.

For this use case, the likely path is a staged approach: validate rubric/output quickly, then move toward Copilot Studio or approved enterprise runtime depending on integration, governance, and source-of-record requirements.

12. Governance and sensitivity

David's concern about sensitivity is valid. People may interpret an EA review assistant as a threat to architect roles. That framing is wrong and risky.

This should be positioned as:

• Reducing repetitive first-pass review work.
• Improving consistency across reviewers.
• Capturing institutional knowledge.
• Making missing evidence visible earlier.
• Giving architects better evidence before decisions.
• Preserving human approval and judgment.

It should not be positioned as:

• Replacing architects.
• Automating ARB approval.
• Removing judgment.
• Treating architecture as a binary checklist.
• Using AI to rubber-stamp submissions.

The message is simple: architects remain accountable. The assistant improves the evidence, preparation, and consistency around the decision.

13. Data architecture and source authority

This is the heaviest lift and the least optional part.

The assistant can only be trusted if it knows which sources are authoritative, which sources are reference-only, which sources are stale, which sources are submission evidence, and which sources are not eligible to support findings.

13.1 Required source classes

13.2 Authority levels

13.3 Evidence states

Every review control should resolve to one of these states:

• Pass
• Gap
• Not evidenced
• Exception required
• Not applicable
• Human review required

“Not evidenced” is critical. It prevents the assistant from inventing completeness when the submission simply lacks enough information.

14. Review criteria and control model

The review model should start narrow, but it must be structurally correct.

14.1 Candidate review dimensions

14.2 Control structure

A control should include:

• Control ID
• Name
• Category
• Rule statement
• Applicability condition
• Required evidence
• Pass condition
• Gap condition
• Not-evidenced condition
• Severity
• Source authority
• Remediation guidance
• Human review trigger

This converts architecture judgment into a reviewable, traceable, human-governed model.

15. Reference implementation tracks

Track A: Copilot / Agent Builder discovery prototype

Use this only to test the interaction model, initial prompts, output shape, and user reaction with a very small group. It should not be treated as the production architecture.

Best for:

• Rapid concept validation
• Small group review
• Prompt/output exploration
• Low integration needs

Risks:

• Limited lifecycle governance
• Limited integration depth
• Not ideal for decision memory or operational controls

Track B: Copilot Studio governed pilot

Use this when the pilot needs controlled access, M365 knowledge grounding, Teams/SharePoint interaction, workflow, analytics, and a more governed agent model.

Best for:

• 7-to-30 user pilot
• Team-level assistant
• M365 collaboration integration
• Basic workflow and review routing

Risks:

• Platform governance path must be confirmed
• Some source-of-record integration may require additional services
• Complex orchestration may exceed low-code comfort

Track C: Enterprise stack implementation

Use this for a durable product that integrates with the AI Governance Portal, architecture repositories, CMDB, catalog tools, decision stores, telemetry, and enterprise orchestration.

Best for:

• Production-grade architecture review capability
• Durable decision memory
• System-of-record integration
• Complex workflow and audit requirements
• Azure/AWS hybrid implementation

Risks:

• More engineering required
• More governance required
• Requires product ownership and sustainment funding

16. Minimum viable product backlog

Epic 1: Intake and source package

• Define first review type.
• Define pilot submission package.
• Identify source-of-record for submissions.
• Build controlled upload or read-only artifact ingestion path.
• Validate supported file types.

Epic 2: Source authority and configuration

• Finalize source authority map.
• Finalize initial tool catalog.
• Finalize initial reference patterns.
• Finalize initial control library.
• Version the configuration package.

Epic 3: Extraction and normalization

• Extract text and metadata from submitted artifacts.
• Normalize extracted facts into submission schema.
• Detect missing evidence.
• Map technologies to catalog entries.
• Flag uncertain extraction for human review.

Epic 4: Control evaluation

• Apply intake completeness checks.
• Apply technology and platform checks.
• Apply data readiness checks.
• Apply security and operational readiness checks.
• Generate evidence-backed findings.

Epic 5: Human reviewer workflow

• Present summary, scorecard, findings, evidence, and missing information.
• Allow accept, reject, edit, override, and rationale capture.
• Capture final decision posture.
• Export review output.

Epic 6: Decision memory and telemetry

• Store final decision record.
• Store standards/control version used.
• Track override rate, false positives, false negatives, cycle-time savings, and adoption.
• Feed approved decisions into reusable memory.

17. Delivery roles, skills, and resourcing model

If this becomes a build initiative, the next question is not only what platform we use. The next question is who actually does the work, who owns the durable assets, and what level of investment is reasonable for the first pilot.

The answer should be deliberately modest for v1. We do not need a huge delivery army to prove the concept. We do need the right split of product ownership, architecture judgment, data/control modeling, and engineering implementation. One highly capable engineer can do a surprising amount if the scope is contained and the platform path is clear. One highly capable engineer cannot also be the EA product owner, data steward, governance approver, security reviewer, prompt/control librarian, and adoption lead. That way lies the traditional enterprise ritual of asking one person to be a department and acting surprised when they become carbon.

17.1 Core team for a controlled alpha

17.2 Skills needed

17.3 Practical staffing scenarios

17.4 Supplier or Rob C team role

The clean boundary is this: internal owners define the review brain; technical augmentation helps wire the system together.

Internal ownership should include product intent, review criteria, semantic/control model, source authority, data classification, prioritization, exception rules, output model, and decision memory. Rob C's team or a supplier can help with connectors, identity/RBAC, Copilot/Copilot Studio or enterprise-stack mechanics, workflow/orchestration, telemetry, deployment, and platform compliance.

This is not anti-supplier. It is anti-outsourcing-the-part-only-we-understand. Subtle distinction, often missed by people selling roadmaps.

18. TCO, tokenomics, and value gate

Every AI or agentic use case should be required to pass a basic economic reality check before it moves forward. This project should hold itself to the same standard. If a team cannot explain what it will cost to build, what it will cost to run, what licensing or token exposure exists, who will maintain it, and what value it creates, then the use case is not ready for approval.

That is especially important here because the enterprise may have favorable near-term economics through Microsoft 365 Copilot and Copilot Studio licensing. That helps, but it is not a permanent architectural strategy. Licensing can change. Token policies can change. Model availability can change. Usage patterns can surprise everyone, because nothing says enterprise innovation like discovering the invoice after the demo.

18.1 Cost categories that must be estimated

18.2 Tokenomics and runtime questions

18.3 Value model

Value must be classified before it is judged. A proposal may be useful and still fail the current approval test if it does not match the decision context.

All value classes matter, but not equally in every business climate. When the immediate decision context is an OPEX reduction mandate, direct savings from an accountable operational budget may be the only class that materially changes the decision.

• Decision owner: decides whether the proposal clears the current line.
• Budget owner: owns the operating budget or capacity being affected.
• Benefiting owner: receives the service, cost, risk, or quality benefit if the claim is true.
• Evidence owner: owns the numbers, baseline, or operational proof behind the claim.

The Outcome Acceptance Line is the current threshold for approval. A proposal can show real value and still sit below the line. Below-line items may still warrant sandboxing, time-boxed feasibility, an explicit exception, or a stop decision.

The first pilot should not claim enterprise-wide transformation. It should prove a measurable local value hypothesis.

Pilot measurement examples:

18.4 Alpha-level investment bands

These are planning bands, not budget commitments. They should be replaced with actual internal rates, platform costs, and sourcing assumptions once the delivery path is selected.

18.5 Approval gate for any future AI/agentic submission

A future submission should be considered incomplete if it cannot answer these questions:

1. What business problem is being solved?
2. What value class is claimed, and what measurable value is expected?
3. Who owns the decision, the impacted budget or capacity, the benefit, and the evidence?
4. Why is AI or agentic automation appropriate?
5. What deterministic alternative was considered?
6. What data is required and who owns it?
7. What sources are canonical, reference-only, or prohibited?
8. What platform path is proposed and why?
9. What governance reviews are triggered?
10. What is the expected build effort?
11. What are the expected run costs, including tokenomics where applicable?
12. What is the current business climate weighting most heavily?
13. Is the proposal above or below the Outcome Acceptance Line, and what is the below-line path if it does not clear it?
14. Who owns sustainment after launch?
15. What metrics prove success or failure?
16. What is the stop condition if the value does not materialize?

This is the filter that keeps architecture review from approving AI slop with a budget line. Harsh, yes. Cheaper than cleaning it up later.

18.6 Build difficulty and intelligence-layer economics

The hardest work is not syntax. The hardest work is converting scattered enterprise judgment into governed, testable, versioned decision assets. That is what this package is preparing.

For this product, implementation is secondary to knowledge architecture. The repo, prompts, evaluations, schemas, controls, source authority, and non-inference contract are the product. The code is the delivery mechanism.

This is probably 60-75% of the hard risk-reduction work, but not necessarily 60-75% of total labor hours. Integration with enterprise systems can still be slow and expensive. The difference is that integration pain is estimable and testable. Ambiguity in source authority, evidence, controls, classification, and decision ownership is harder to estimate and more dangerous to outsource.

The practical build-versus-buy rule is direct: outsource wiring, workflow, integrations, orchestration, telemetry plumbing, and deployment mechanics where it makes sense. Do not outsource the architecture intelligence layer unless the enterprise is willing to rent back its own decision logic through future change orders, which would be an unusually expensive way to discover gravity.

Before approving a build or vendor engagement, leadership should ask whether the enterprise is willing and able to own these internal assets:

1. Source authority and source conflict rules.
2. Review criteria and control library.
3. Data classification and evidence requirements.
4. Non-inference and escalation behavior.
5. Evaluation fixtures and expected outputs.
6. Human approval and override workflow.
7. Decision memory and exception rationale.
8. Sustainment model for standards, controls, prompts, and schemas.

If those assets cannot be owned internally, the right answer may not be to buy a smarter agent. The right answer may be to improve the underlying governance operating model first. Otherwise the enterprise will automate ambiguity, then pay someone to explain why the automation is ambiguous.

A useful leadership framing is this:

The hard part is not building a chatbot. The hard part is codifying how the enterprise makes architecture review decisions: which sources are authoritative, what evidence is required, what controls apply, what must never be inferred, how exceptions are handled, and how human architects approve or override the output. Once that architecture intelligence layer is defined, engineering becomes implementation. Without it, engineering just automates ambiguity.

19. Build Readiness, Repo Bootstrap, and Evaluation Discipline

This section is the final bridge between alignment and development. The intent is not to add more ceremonial documentation. The intent is to define the minimum engineering runway so a builder can start from the package without reinterpreting the product vision, guessing at the data model, or burying governance rules in prompt text.

The package should support four different build depths. A simple Copilot experiment should not carry the same burden as an enterprise integrated product, but every path still needs enough rigor to avoid building from vibes.

19.1 Repo bootstrap readiness model

The HTML package should be treated as the human-readable source of truth. The repo bootstrap pack is the machine-actionable payload that can be extracted from the package once scope and platform path are confirmed.

For this Enterprise Architecture Review Assistant, Tier 1 is useful only as a discovery prototype. If we share it with a reviewer group or connect it to enterprise content, it becomes Tier 2. If it integrates with the AI Governance Portal, architecture repository, decision memory, or regulated review path, it becomes Tier 3.

19.2 Requirements-to-artifact traceability

Requirements gathering should not produce meeting notes that die in a folder. Each question should populate an artifact.

This traceability model is what turns intake from a conversation into a buildable source package.

19.3 Evaluation and test fixtures

The assistant should not be trusted because the output looks polished. It should be trusted only after it performs well against a curated fixture set.

The evaluation model should measure extraction correctness, evidence quality, control correctness, missing evidence handling, recommendation quality, source authority behavior, non-inference behavior, reviewer usefulness, and regression stability.

Minimum fixture types should include:

• Complete good submission.
• Incomplete submission.
• Conflicting evidence.
• Restricted or declining technology.
• Missing security model.
• Missing data classification.
• Fast-path claim with risky architecture.
• Duplicate capability scenario.
• GxP or possible-GxP scenario.
• Non-AI deterministic use case.
• Ambiguous submission.
• Adversarial wording.

Happy-path-only testing is how pilots lie. We should not do that to ourselves, even if it would make the demo feel emotionally safer.

19.4 Non-inference and evidence contract

The assistant must not infer approval status, data classification, GxP impact, security control existence, technology approval status, production readiness, ownership, exception approval, business criticality, platform approval, or source authority.

Allowed evidence states should be explicit:

This is the discipline that prevents the assistant from becoming a confident hallucination appliance with a governance logo.

19.5 Control authoring standard

Before review criteria become machine-readable controls, each control should define:

• Control ID.
• Name.
• Category.
• Rule statement.
• Applicability trigger.
• Severity.
• Required evidence.
• Pass criteria.
• Fail criteria.
• Not-evidenced criteria.
• Source authority dependency.
• Recommended remediation.
• Human review requirement.
• Linked reference patterns.
• Version and owner.

Controls should be testable, evidence-bound, versioned, and reviewable by humans. Controls should not be hidden inside prompts where governance goes to become archaeology.

19.6 Build gates and stop conditions

Build should not begin unless the first review type, minimum rubric, source authority, data classification, pilot submissions, platform path, human review flow, run-cost assumptions, and sustainment owner are at least provisionally defined.

Stop or redirect if:

• The assistant guesses instead of marking missing evidence.
• High-risk false negatives appear.
• Architect override rate is too high.
• Source ownership is unresolved.
• Data classification is unknown.
• Run cost exceeds expected value.
• Sustainment ownership is unclear.
• The use case is better solved with deterministic workflow, rules, search, or dashboarding.

The build should proceed only when the next decision is smaller than the last one. If every meeting reveals a new unknown, the project is still in discovery, no matter how many impressive screenshots exist.

19.7 Manual framework harness execution

The framework can be exercised manually before an agent or integrated workflow exists. This is useful for validation, reviewer training, prompt testing, and evidence-loop rehearsal. It must not be treated as architecture approval.

Manual harness execution means a human reviewer uses the HTML, DOCX, Markdown, and repo-bootstrap materials as the review framework, then asks an approved AI assistant or Copilot surface to draft structured analysis against a submitted architecture package.

Manual harness boundary

Manual harness execution steps

1. Confirm the data handling path and selected Copilot/model tier.
2. Remove or redact any material not approved for the chosen tool surface.
3. Open the v1.14.1 HTML or DOCX framework and identify the review sections that apply.
4. Provide the submitted architecture summary and evidence set to the approved assistant.
5. Run the manual harness prompt from repo-bootstrap/prompts/manual-ea-review-harness.prompt.md.
6. Require the assistant to classify all uncertain or missing facts as not_evidenced, requires_confirmation, or requires_escalation.
7. Review the draft output against the source evidence, control logic, and non-inference rules.
8. Record human reviewer actions: accept, edit, reject, override, request evidence, or escalate.
9. Capture the final human-reviewed decision packet only in the approved governance path.

Manual harness output shape

The manual output should include:

• submission summary
• assumptions explicitly marked as assumptions
• evidence inventory
• missing evidence list
• likely review dimensions triggered
• source authority concerns
• AI appropriateness assessment
• platform path assessment
• data/privacy/security/GxP triggers requiring confirmation
• control-style findings with evidence state
• escalation recommendations
• human-review checklist
• final note: Draft review support only - no approval authority

Reusable manual harness prompt

Use the prompt stored in repo-bootstrap/prompts/manual-ea-review-harness.prompt.md. If copied into Copilot or another approved tool, preserve the non-inference rules and the final approval boundary exactly. A prettier prompt that silently weakens governance is still just a decorative liability.

20. From package to repo

The self-contained HTML should be treated as the human-readable source of truth, not as a magic executable specification. The right path is to use the HTML for intent, context, and provenance, then use the repo-bootstrap scaffold and Markdown/JSON/YAML/schema assets as the machine-readable starting point.

The build team should not simply feed the HTML to a model and ask it to "spawn the repo" without constraints. A model can help generate or fill starter files, but only if it is told not to invent missing decisions, not to turn assumptions into defaults, and not to let the agent infer governance-sensitive facts.

Recommended repo-spawn flow

1. Unzip the package into a clean workspace.
2. Copy the repo-bootstrap/ folder into a new repository or approved enterprise repo template.
3. Read the package in order: README, product brief, architecture, engineering orientation, AI appropriateness, governance routing, evaluation strategy, non-inference rules, evidence requirements, and ADRs.
4. Select the delivery tier: simple Copilot prototype, Copilot Studio governed pilot, or enterprise integrated product.
5. Validate required files using the bootstrap manifest and completeness checklist.
6. Replace placeholders with real decisions or mark them as needs_decision.
7. Validate schemas, controls, catalogs, and source authority files before coding against them.
8. Build the first evidence loop before building a polished UI.
9. Create a golden test set with expected outputs.
10. Do not start broader development until build gates pass.

What the engineer should use

Completion criteria

The repo is ready for first development only when the product brief, platform path, source authority, data classification, minimum controls, output schema, non-inference contract, test fixtures, human review workflow, run-cost assumptions, and sustainment ownership are present or explicitly marked as unresolved decisions.

If that sounds like discipline, good. It is much cheaper than debugging ambiguity after a team has already built the wrong thing.

21. Agent readiness posture v1.14.1

v1.14.1 carries forward the v1.13 agent-readiness work and fixes residual handoff hygiene defects that could make active surfaces look less trustworthy than the underlying package. The target remains narrow: make the package easier for humans to approve, engineers to implement, and agents to consume without guessing.

The current release keeps the operating contract, work modes, manifest, fixture structure, observability expectations, human review workflow, artifact pairing guidance, and prompt/instruction quality standard. It also tightens schema behavior, fixture coverage, reference-pattern/control alignment, and validation.

21.1 Current execution-preparation assets

21.2 Historical provenance boundary

Earlier source cards and archived package material remain useful provenance. They are not current release metadata and must not be treated as canonical enterprise authority unless a current v1.14.1 artifact explicitly points to them.

The package now separates current execution-preparation assets from historical source-library material more clearly. This matters because stale version labels can cause engineers to trust the wrong artifact, which is how small handoff defects become meetings.

21.3 Agent operating model

Agents start in analyze_only. They may inspect, compare, validate syntax, and report gaps. They may not edit until the user explicitly opens the edit gate.

When edits are approved, agents must work in a bounded mode, update the manifest when structure changes, validate modified JSON and schemas, preserve source provenance, and report unresolved decisions.

If a task requires approval status, data classification, GxP impact, source authority, exception status, technology approval, production readiness, platform approval, funding, ownership, privacy/PII/PHI posture, or compliance posture, the agent must stop or mark the item as not_evidenced, requires_confirmation, or requires_escalation.

21.4 Current readiness posture

21.5 v1.14.1 stop condition

Do not treat v1.14.1 as autonomous governance, pilot approval, production approval, or vendor-owned review logic. It is a controlled build-preparation runway. Build may proceed only while unresolved enterprise decisions remain visible, named, and blocked from becoming fake defaults.

22. Build versus buy boundary

Own internally

• Product vision
• Review criteria
• Source authority
• Data classification
• Semantic/control model
• Reference patterns
• Exception logic
• Decision memory
• Approval model
• Quality and governance rules

Supplier-assisted

• UI implementation
• Connector configuration
• Copilot Studio build mechanics
• Azure/AWS orchestration implementation
• Workflow automation
• Runtime deployment
• Logging and telemetry plumbing
• Test harness and evaluation tooling

Avoid

• Vendor-owned control library
• Vendor-owned standards interpretation
• Vendor-owned decision memory
• Duplicate intake portal that bypasses the existing system of record
• Black-box scoring that architects cannot challenge
• Perpetual maintenance dependency for changes the enterprise should own

23. Delta needed before build

24. Immediate working plan for David and Tony

David leads

• Architecture review criteria
• EA principles and standards interpretation
• Reference patterns and anti-patterns
• Human review and approval model
• Reviewer expectations
• Leadership positioning and sensitivity handling

Tony leads

• Product framing
• Data/control model structure
• Source authority packaging
• Engineering orientation
• Platform-fit analysis
• Supplier boundary and delivery mechanics

Together

• Confirm first use case.
• Define minimum viable rubric.
• Select pilot submissions.
• Agree on output model.
• Decide which platform path to test first.
• Define what help is needed from Rob C's team or another technical resource.

25. Recommended next move

Schedule a focused working session to lock the build-readiness foundation. The session should not attempt to design the entire platform. It should answer enough to start a controlled evidence-loop implementation proof.

Suggested agenda:

1. Confirm first review type.
2. Confirm first user group.
3. Walk the minimum review rubric.
4. Identify authoritative standards and catalogs.
5. Confirm source-of-record for submitted artifacts.
6. Confirm platform path candidates.
7. Identify governance gates.
8. Define pilot success metrics.
9. Identify what Rob C's team or another technical resource would own.

The output should be a one-page build-preparation charter, a source authority map, a minimum control library, a fixture-backed submission set, and a build decision for the first technical path.

26. v1.14.1 Copilot platform-alignment, manual-harness, and navigation-restoration patch

v1.14.1 is a narrow controlled addendum over the v1.13.1 baseline. It does not change the product thesis, audience model, strategy, review model, build-versus-buy boundary, control scope, pilot boundary, production boundary, or governance authority model.

The patch adds enterprise Copilot platform alignment, adds a manual framework harness execution path, adds repo-bootstrap prompt/template assets for manual review rehearsal, restores the full HTML navigation/source-library surface after the v1.14.1 compression regression, updates readiness posture conservatively, and refreshes validation and hash artifacts.

26.1 What was added or tightened

26.2 What remains intentionally unresolved

The Copilot platform context validates the staged model; it does not implement the agent or approve pilot expansion. These items still require named enterprise owners before pilot expansion:

26.3 v1.14.1 go/no-go position

v1.14.1 is ready for controlled evidence-loop build preparation and manual framework harness rehearsal using approved data and approved tool surfaces, with the full HTML navigation and source-library handoff surface restored. It is not ready for broad pilot, autonomous approval, production routing, or vendor-owned control logic.

The correct next gate is either:

1. a manual harness test using sanitized or approved sample submissions, or
2. a small implementation proof that loads fixtures, applies source authority, evaluates controls, produces evidence-bound findings, rejects unsupported inference, routes to human review, captures reviewer actions, and records reviewer overrides.

If the manual harness or implementation proof fails, fix the review brain before building a prettier interface. That sentence has now survived enough deck trauma to qualify as policy.

python -m json.tool BOOTSTRAP_MANIFEST.json >/dev/null
python -m json.tool agent-work-modes.json >/dev/null
python -m json.tool schemas/architecture-submission.schema.json >/dev/null
python -m json.tool schemas/review-output.schema.json >/dev/null
python -m json.tool schemas/test-fixture-metadata.schema.json >/dev/null

tests/
  README.md
  fixtures/
    sample/
      fixture-metadata.json
      submitted-artifacts/
      source-notes.md
  expected-outputs/
    sample/
      expected-review-output.json
      expected-findings.md

{
  "package_name": "Enterprise Architecture Review Assistant",
  "package_version": "v1.8",
  "created_date": "2026-06-14",
  "purpose": "Machine-readable manifest for repo bootstrap completeness, agent readiness, and build-readiness gating.",
  "source_baseline": [
    "uploaded v1.7 ZIP",
    "uploaded v1.7 self-contained HTML"
  ],
  "pattern_reference": [
    "pinklon/sourcemesh-artifact-plane AGENTS.md and repo operating discipline reviewed as a pattern reference only"
  ],
  "readiness_scores": {
    "human_package": 92,
    "repo_bootstrap": 88,
    "agent_readiness": 90
  },
  "artifact_inventory": [
    {
      "path": "AGENTS.md",
      "type": "agent_instruction",
      "audience": [
        "ai_agents",
        "engineers"
      ],
      "purpose": "Root coding-agent operating contract and non-inference boundary.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": ".github/copilot-instructions.md",
      "type": "agent_instruction",
      "audience": [
        "ai_agents",
        "engineers"
      ],
      "purpose": "GitHub Copilot repository instruction pointer.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "README.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "PRODUCT_BRIEF.md",
      "type": "human_readable",
      "audience": [
        "executives",
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "AI_APPROPRIATENESS.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "GOVERNANCE_ROUTING.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "ARCHITECTURE.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "ENGINEERING_ORIENTATION.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "BACKLOG.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "EVALUATION_STRATEGY.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": "TEST_FIXTURE_PLAN.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Fixture taxonomy and regression testing model.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": "NON_INFERENCE_RULES.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": "EVIDENCE_REQUIREMENTS.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_1",
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": "HUMAN_REVIEW_WORKFLOW.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Human review, override, escalation, and approval boundary.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": true
    },
    {
      "path": "OBSERVABILITY.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Trace, event, metric, cost, and override telemetry contract.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "TCO_TOKENOMICS.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "SUPPORT_MODEL.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "SPAWN_REPO_INSTRUCTIONS.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "COMPLETENESS_CHECKLIST.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Human-readable completeness checklist and readiness scoring guide.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "READINESS_SCORECARD.md",
      "type": "human_readable",
      "audience": [
        "executives",
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Current human, repo, and agent readiness posture.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "ARTIFACT_PAIRING_GUIDE.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Pairing rules for human-readable and agent-readable artifacts.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "PROMPT_INSTRUCTION_QUALITY_STANDARD.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Quality standard for prompts and agent instructions.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "SOURCE_PROVENANCE.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Baseline package and SourceMesh pattern-reference provenance.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "agent-work-modes.json",
      "type": "machine_readable",
      "audience": [
        "ai_agents",
        "engineers"
      ],
      "purpose": "Machine-readable agent work modes and allowed actions.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "adr/ADR-0001-own-the-brain.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "adr/ADR-0002-platform-path.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "adr/ADR-0003-human-approval.md",
      "type": "human_readable",
      "audience": [
        "ea_governance",
        "engineers",
        "ai_agents"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "schemas/architecture-submission.schema.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "schemas/review-output.schema.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "schemas/test-fixture-metadata.schema.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "controls/control-library.seed.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "controls/control-to-pattern-map.seed.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "catalogs/source-authority-map.seed.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "catalogs/tool-catalog.seed.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "catalogs/reference-pattern-library.seed.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.7 repo-bootstrap seed",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "tests/README.md",
      "type": "human_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "tests/fixtures/README.md",
      "type": "human_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "tests/fixtures/sample/fixture-metadata.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    },
    {
      "path": "tests/expected-outputs/README.md",
      "type": "human_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / product owner",
      "validation": "human_review",
      "blocks_build_if_missing": false
    },
    {
      "path": "tests/expected-outputs/sample/expected-review-output.json",
      "type": "machine_readable",
      "audience": [
        "engineers",
        "ai_agents",
        "ea_governance"
      ],
      "purpose": "Seed artifact required for build readiness or evaluation discipline.",
      "required_for_tiers": [
        "tier_2",
        "tier_3"
      ],
      "current_state": "present_seed",
      "completion_state": "seeded_needs_owner_validation",
      "source": "v1.8 hardening pass",
      "owner_to_confirm": "EA governance / engineering",
      "validation": "json_syntax",
      "blocks_build_if_missing": false
    }
  ],
  "required_directories": [
    "adr",
    "schemas",
    "controls",
    "catalogs",
    "tests",
    "tests/fixtures",
    "tests/expected-outputs",
    ".github"
  ],
  "required_decisions_before_build": [
    "first_review_type",
    "platform_path",
    "source_authority",
    "data_classification",
    "minimum_control_set",
    "human_review_workflow",
    "run_cost_assumptions",
    "sustainment_owner",
    "pilot_fixture_set",
    "observability_retention_boundary"
  ],
  "allowed_evidence_states": [
    "supported",
    "not_evidenced",
    "conflicting_evidence",
    "requires_confirmation",
    "requires_escalation",
    "not_applicable"
  ],
  "do_not_infer": [
    "approval_status",
    "data_classification",
    "gxp_impact",
    "security_control_existence",
    "technology_approval_status",
    "production_readiness",
    "ownership",
    "exception_approval",
    "business_criticality",
    "platform_approval",
    "source_authority",
    "privacy_or_pii_posture",
    "operational_readiness",
    "funding_approval"
  ],
  "agent_work_modes_ref": "agent-work-modes.json",
  "human_approval_required": true,
  "build_ready_when": [
    "manifest_required_artifacts_present",
    "json_files_validate",
    "first_review_type_selected",
    "source_authority_confirmed_for_pilot",
    "data_classification_confirmed_for_pilot",
    "fixtures_and_expected_outputs_populated",
    "human_review_workflow_accepted",
    "observability_contract_accepted",
    "sustainment_owner_named"
  ]
}

unzip EA_Architecture_Review_Assistant_David_Package_v1.7.zip -d ea-review-assistant-package
cd ea-review-assistant-package

mkdir ea-review-assistant
cp -R repo-bootstrap/* ea-review-assistant/
cd ea-review-assistant

README.md
PRODUCT_BRIEF.md
AI_APPROPRIATENESS.md
GOVERNANCE_ROUTING.md
ARCHITECTURE.md
ENGINEERING_ORIENTATION.md
BACKLOG.md
EVALUATION_STRATEGY.md
NON_INFERENCE_RULES.md
EVIDENCE_REQUIREMENTS.md
TCO_TOKENOMICS.md
SUPPORT_MODEL.md
adr/
schemas/
controls/
catalogs/
tests/

Use the attached Enterprise Architecture Review Assistant package and repo-bootstrap scaffold.
Do not invent missing decisions.
Generate only the files listed in the bootstrap manifest.
If required information is missing, mark the field as needs_decision.
Do not convert assumptions into defaults.
Do not make the agent an approver.
Preserve the non-inference and evidence contract.

{
  "control_id": "EA-AI-DATA-001",
  "name": "AI use case declares data classification",
  "category": "data_readiness",
  "rule_statement": "All AI-enabled architecture submissions must declare the classification of each input and output data source.",
  "applicability_trigger": "applies_when: submission.includes_ai_capability == true",
  "severity": "high",
  "required_evidence": ["data classification table", "source inventory", "data flow description"],
  "pass_criteria": "Each data source and output has an explicit classification and owner.",
  "fail_criteria": "One or more data sources are described but classification is absent or contradicted.",
  "not_evidenced_criteria": "Submission does not include a data classification section or equivalent evidence.",
  "source_authority_dependency": "canonical_or_authorized_submission_artifact",
  "recommended_remediation": "Provide data classification, data owner, and allowed processing location for each source and output.",
  "human_review_required": true,
  "linked_patterns": ["PAT-AI-GOV-DATA-001"],
  "version": "0.1",
  "owner": "EA/Data Governance",
  "effective_date": "TBD"
}