diff --git a/INTENT.md b/INTENT.md
new file mode 100644
index 0000000..07f0981
--- /dev/null
+++ b/INTENT.md
@@ -0,0 +1,205 @@
+# open-reuse
+
+*Managed continuity for valuable open-source integrations.*
+
+## 1. Intent
+
+open-reuse exists to transform proven integrations with open-source software into **structured, maintainable, and automatically managed integration assets**.
+
+In practice, valuable integrations are often created pragmatically: a component is reused, a service is adapted, a module is extracted, or a system is extended. Once such integrations demonstrate real-world value, they become long-term dependencies on upstream evolution.
+
+open-reuse provides a framework and service model to ensure that these integrations remain **robust, transparent, and continuously maintainable** over time.
+
+The goal is not merely reuse, but **sustainable reuse under change**.
+
+---
+
+## 2. Problem Statement
+
+Open-source reuse commonly suffers from the following failure modes:
+
+- Integrations are **implicit and undocumented**
+- Boundaries between systems are **unclear or leaky**
+- Upstream changes introduce **silent breakage or drift**
+- Updates are **manual, inconsistent, or postponed**
+- Forks and patches become **unmaintainable technical debt**
+- Responsibility is **unclear or lost over time**
+
+As a result, initially valuable integrations degrade into fragile liabilities.
+
+---
+
+## 3. Core Idea
+
+open-reuse treats every valuable integration as a **first-class, managed artifact**.
+
+A working integration is:
+
+1. **Analyzed** — its structure and dependencies are understood  
+2. **Classified** — its reuse mode is explicitly defined  
+3. **Refactored** — clear boundaries and interfaces are established  
+4. **Reframed** — it is expressed as an *Integration Definition*  
+5. **Registered** — it becomes part of the open-reuse system  
+6. **Maintained** — it is continuously monitored, validated, and updated  
+
+Automation handles the default case.  
+Humans intervene only when necessary.
+
+---
+
+## 4. Lifecycle
+
+```text
+Build Integration
+→ Prove Value
+→ Analyze Integration
+→ Classify Reuse Mode
+→ Refactor Boundaries
+→ Create Integration Definition
+→ Register Integration
+→ Monitor Upstream Changes
+→ Auto-update + Validate
+→ Escalate if Required
+````
+
+open-reuse explicitly starts **after an integration has proven its value**.
+
+---
+
+## 5. Key Concepts
+
+### Integration
+
+A working reuse relationship between a local system and upstream open-source software.
+
+### Proven Integration
+
+An integration that has been built, tested, and validated as useful in practice.
+
+### Integration Definition
+
+A structured, machine-readable description of an integration, including:
+
+* upstream sources
+* reuse mode
+* boundaries and interfaces
+* update policies
+* validation requirements
+
+### Reuse Mode
+
+The classified pattern of reuse, such as:
+
+* dependency
+* plugin
+* adapter
+* component extraction
+* patch overlay
+* fork continuation
+
+### Reuse Boundary
+
+A clearly defined interface that isolates local systems from upstream change.
+
+### Validation Harness
+
+A set of automated checks ensuring the integration remains functional and compliant.
+
+### Update Policy
+
+Rules governing how upstream changes are handled (automatic, reviewed, blocked).
+
+### Maintainer
+
+A responsible party notified when automation cannot safely proceed.
+
+### Escalation Case
+
+A condition requiring human inspection, such as:
+
+* breaking changes
+* failed validation
+* security issues
+* license changes
+
+---
+
+## 6. System Responsibilities
+
+open-reuse provides:
+
+* A **registry** for integration definitions
+* Continuous **upstream monitoring**
+* **Impact analysis** for upstream changes
+* Automated **update execution** where safe
+* **Validation pipelines** for correctness and compliance
+* **Escalation mechanisms** to maintainers
+* A transparent **audit trail** of integration evolution
+
+---
+
+## 7. Design Principles
+
+### Explicit over implicit
+
+All integrations must be defined, structured, and inspectable.
+
+### Boundaries first
+
+Every integration must expose a clear and controlled interface.
+
+### Automate the default
+
+Safe updates and validations should require no human intervention.
+
+### Human-in-the-loop for uncertainty
+
+Ambiguous or high-risk changes must be escalated.
+
+### Preserve upstream alignment
+
+Prefer adaptation and composition over forks and divergence.
+
+### Keep knowledge executable
+
+All integration knowledge must be encoded in version-controlled artifacts.
+
+---
+
+## 8. Scope
+
+open-reuse focuses on:
+
+* Integrations between open-source applications and systems
+* Long-lived reuse relationships requiring maintenance
+* Automated handling of upstream evolution
+
+open-reuse does **not** aim to:
+
+* Replace package managers
+* Replace CI/CD systems
+* Act as a generic integration platform
+* Manage initial integration development
+
+It complements these by managing **what happens after integration success**.
+
+---
+
+## 9. Vision
+
+A world where reuse of open-source software is:
+
+* **Reliable** — integrations do not silently degrade
+* **Transparent** — dependencies and boundaries are explicit
+* **Maintainable** — updates are continuous and systematic
+* **Scalable** — reuse can grow without accumulating hidden risk
+
+open-reuse enables organizations to build on open-source ecosystems
+without turning integration into long-term fragility.
+
+---
+
+## 10. One-Sentence Summary
+
+open-reuse turns proven open-source integrations into structured, registered, and automatically maintained assets with explicit boundaries, validation, and controlled evolution.
+
diff --git a/ProductRequirementsDocument.md b/ProductRequirementsDocument.md
new file mode 100644
index 0000000..428dc9f
--- /dev/null
+++ b/ProductRequirementsDocument.md
@@ -0,0 +1,1020 @@
+# open-reuse PRD
+
+*Product Requirements Document*
+
+## 1. Document Status
+
+**Product:** open-reuse  
+**Document Type:** Product Requirements Document  
+**Status:** Draft v0.1  
+**Primary Audience:** Product, engineering, maintainers, platform teams, open-source integration owners  
+**Related Artifacts:** INTENT.md, future Integration Definition Schema, future Functional Requirements Specification  
+**Framing Reference:** This PRD follows the InfoTechPrimer understanding of a PRD as a product-definition artifact that captures purpose, scope, constraints, and success criteria without prescribing implementation details. :contentReference[oaicite:0]{index=0}
+
+---
+
+## 2. Product Summary
+
+**open-reuse** is a framework and service for transforming valuable open-source integrations into structured, registered, and automatically maintained integration assets.
+
+It starts after an integration has already been built, tested, and deemed useful. open-reuse then helps analyze, classify, refactor, reframe, register, monitor, validate, update, and escalate that integration as upstream open-source code evolves.
+
+The product exists to prevent valuable open-source reuse from degrading into hidden coupling, unmanaged forks, brittle patches, silent drift, or long-term technical debt.
+
+---
+
+## 3. One-Sentence Product Definition
+
+**open-reuse turns proven open-source integrations into structured, registered, and automatically maintained assets with explicit boundaries, validation, update policies, and maintainer escalation.**
+
+---
+
+## 4. Problem Statement
+
+Open-source software is frequently reused across systems in pragmatic and valuable ways. Teams adapt components, depend on APIs, embed modules, copy useful code, patch upstream projects, or maintain lightweight forks.
+
+These integrations often begin as successful engineering work. However, once they become important, they create a continuing dependency on upstream evolution.
+
+Common failure modes include:
+
+- The integration is not explicitly documented.
+- The reused upstream surface is unclear.
+- The boundary between local system and upstream project is leaky.
+- Updates are handled manually and inconsistently.
+- Breaking upstream changes are discovered too late.
+- Security or license changes are missed.
+- Local patches become difficult to understand.
+- Forks silently diverge from upstream.
+- Responsibility for the integration becomes unclear.
+- Maintainers are notified only after something has already broken.
+
+The result is that reuse, initially a strength, becomes a source of fragility.
+
+open-reuse addresses this by making open-source reuse explicit, classified, testable, monitorable, and maintainable under change.
+
+---
+
+## 5. Product Intent
+
+open-reuse exists to provide a structured lifecycle for valuable open-source integrations after they have proven their usefulness.
+
+The product shall support the transition from:
+
+```text
+Working but informal integration
+````
+
+to:
+
+```text
+Registered, classified, validated, and automatically maintained integration asset
+```
+
+The core product intent is to make sustainable reuse of open-source software possible at scale without relying on undocumented human memory or ad-hoc maintenance discipline.
+
+---
+
+## 6. Target Users
+
+### 6.1 Primary Users
+
+#### Integration Maintainers
+
+People or teams responsible for keeping a specific integration functional over time.
+
+They need:
+
+* Clear visibility into upstream changes
+* Escalation when automation cannot safely proceed
+* Evidence about why an update passed or failed
+* Traceability of integration decisions
+
+#### Platform Engineering Teams
+
+Teams responsible for reusable internal platforms, developer experience, shared services, or enterprise architecture.
+
+They need:
+
+* A registry of integration assets
+* Standardized integration definitions
+* Update automation
+* Policy-based control
+* Auditable governance
+
+#### Product Engineering Teams
+
+Teams that build products by integrating open-source tools or components.
+
+They need:
+
+* A way to operationalize valuable integrations
+* Protection against upstream breakage
+* Reduced long-term maintenance burden
+* Reliable dependency evolution
+
+---
+
+### 6.2 Secondary Users
+
+#### Security Teams
+
+They need visibility into reused upstream code, security advisories, dependency exposure, and risky update conditions.
+
+#### Legal / Compliance Teams
+
+They need visibility into license changes, attribution requirements, and reuse patterns that may trigger compliance obligations.
+
+#### Open-Source Program Offices
+
+They need a structured view of how open-source software is reused internally and where upstream collaboration may be beneficial.
+
+#### AI / Automation Agents
+
+They may act as analysis, transformation, validation, or maintenance assistants operating on registered integration definitions.
+
+---
+
+## 7. Product Goals
+
+### Goal 1: Make integrations explicit
+
+open-reuse shall provide a structured way to describe open-source integrations, including upstream sources, reuse mode, local boundaries, validation requirements, update policies, and maintainers.
+
+### Goal 2: Classify reuse risk
+
+open-reuse shall classify integrations by reuse pattern and associated maintenance risk.
+
+Examples:
+
+* Dependency reuse
+* Plugin reuse
+* Adapter reuse
+* Component extraction
+* Patch overlay
+* Fork continuation
+
+### Goal 3: Support systematic refactoring into maintainable boundaries
+
+open-reuse shall help teams reframe valuable integrations around explicit boundaries so upstream change can be isolated and tested.
+
+### Goal 4: Register integrations as managed assets
+
+open-reuse shall provide a registry where structured integration definitions can be stored, inspected, searched, and governed.
+
+### Goal 5: Monitor upstream change
+
+open-reuse shall track upstream releases, commits, tags, dependency updates, security advisories, license changes, and other relevant signals.
+
+### Goal 6: Validate integration continuity
+
+open-reuse shall support automated validation of whether a registered integration still works after upstream change.
+
+### Goal 7: Automate safe maintenance
+
+open-reuse shall support automated update attempts, validation runs, reporting, and update proposals where risk is acceptable.
+
+### Goal 8: Escalate uncertainty to humans
+
+open-reuse shall notify registered maintainers when automation cannot safely complete an update or when policy requires review.
+
+### Goal 9: Preserve traceability
+
+open-reuse shall maintain an audit trail of integration definitions, upstream versions, update attempts, validation results, maintainer actions, and escalation decisions.
+
+---
+
+## 8. Non-Goals
+
+open-reuse shall not initially aim to:
+
+* Replace package managers
+* Replace CI/CD systems
+* Replace source control platforms
+* Replace dependency update tools
+* Replace security scanners
+* Replace software composition analysis tools
+* Become a general workflow automation platform
+* Build initial integrations from scratch
+* Guarantee automatic resolution of all upstream breaking changes
+* Eliminate the need for maintainers
+* Force all integrations into one implementation pattern
+
+open-reuse complements existing developer tools by managing the lifecycle and continuity of valuable integrations.
+
+---
+
+## 9. Product Scope
+
+## 9.1 In Scope
+
+The initial product scope includes:
+
+* Definition of an open-reuse Integration Definition format
+* Registration of integration definitions
+* Classification of reuse modes
+* Assignment of maintainers
+* Tracking of upstream source references
+* Tracking of local integration boundaries
+* Definition of update policies
+* Definition of validation requirements
+* Upstream monitoring
+* Change impact classification
+* Automated validation triggers
+* Escalation to maintainers
+* Status reporting
+* Audit trail of integration lifecycle events
+
+---
+
+## 9.2 Out of Scope for Initial Version
+
+The following are out of scope for the first product version:
+
+* Fully autonomous code migration for all languages
+* Full semantic understanding of arbitrary application architectures
+* Complete legal compliance automation
+* Complete vulnerability remediation automation
+* Hosting of upstream code mirrors as a primary function
+* Replacement of Renovate, Dependabot, OpenRewrite, CI systems, or SCA tools
+* Multi-tenant enterprise billing
+* Marketplace functionality
+* Public SaaS operation as the default deployment model
+* Automatic acceptance of risky updates without human approval
+
+---
+
+## 10. Core Lifecycle
+
+open-reuse shall support the following lifecycle:
+
+```text
+Build Integration
+→ Prove Value
+→ Analyze Integration
+→ Classify Reuse Mode
+→ Refactor Boundaries
+→ Create Integration Definition
+→ Register Integration
+→ Monitor Upstream Changes
+→ Analyze Change Impact
+→ Attempt Safe Update
+→ Validate Integration
+→ Report Result
+→ Escalate if Required
+```
+
+Important lifecycle principle:
+
+**open-reuse starts after the integration has proven value.**
+
+It does not primarily optimize initial experimentation. It operationalizes successful reuse before it becomes unmanaged technical debt.
+
+---
+
+## 11. Core Concepts
+
+## 11.1 Integration
+
+A working reuse relationship between a local system and one or more upstream open-source systems, repositories, packages, APIs, services, modules, files, schemas, or artifacts.
+
+## 11.2 Proven Integration
+
+An integration that has been built, tested, and deemed valuable enough to preserve and maintain.
+
+## 11.3 Integration Definition
+
+A structured, machine-readable description of a proven integration.
+
+It includes:
+
+* Integration identity
+* Upstream source references
+* Reuse mode
+* Reused surfaces
+* Local boundaries
+* Validation requirements
+* Update policies
+* Maintainer assignments
+* Escalation conditions
+* Audit metadata
+
+## 11.4 Reuse Mode
+
+The classified pattern by which upstream open-source functionality is reused.
+
+Initial reuse modes:
+
+| Reuse Mode           | Description                                                   | Relative Risk |
+| -------------------- | ------------------------------------------------------------- | ------------- |
+| Dependency reuse     | Upstream is consumed as a package, library, image, or service | Low           |
+| Plugin reuse         | Upstream is extended through official extension points        | Low to medium |
+| Adapter reuse        | Upstream behavior is wrapped behind a local interface         | Medium        |
+| Component extraction | Selected internal parts of upstream are reused                | High          |
+| Patch overlay        | Local patches are maintained on top of upstream               | High          |
+| Fork continuation    | A local fork evolves separately but remains upstream-aware    | Very high     |
+
+## 11.5 Reuse Boundary
+
+The explicit local seam between the host system and the reused upstream functionality.
+
+Examples:
+
+* Interface
+* Port
+* Adapter
+* Wrapper service
+* API facade
+* Plugin boundary
+* CLI boundary
+* Schema boundary
+* Event contract
+* File-level copy boundary
+
+## 11.6 Validation Harness
+
+The set of automated checks used to determine whether the integration still works.
+
+Examples:
+
+* Unit tests
+* Contract tests
+* Integration tests
+* Golden-path tests
+* Snapshot tests
+* Build checks
+* API compatibility checks
+* Schema compatibility checks
+* Security scans
+* License checks
+
+## 11.7 Update Policy
+
+Rules determining how upstream changes are handled.
+
+Example outcomes:
+
+* Ignore
+* Monitor only
+* Open issue
+* Open update proposal
+* Open pull request
+* Auto-merge after validation
+* Require maintainer review
+* Block update
+* Trigger escalation
+
+## 11.8 Maintainer
+
+A registered responsible person, team, group, or automation identity accountable for reviewing escalations and maintaining the integration.
+
+## 11.9 Escalation Case
+
+A situation where automation cannot safely proceed or policy requires human inspection.
+
+Examples:
+
+* Failed validation
+* Breaking API change
+* Changed license
+* Security advisory
+* Upstream deletion or archival
+* Patch conflict
+* Fork divergence
+* Unknown change impact
+* Missing maintainer
+* Repeated automation failure
+
+---
+
+## 12. Functional Product Capabilities
+
+This section describes product-level capabilities without prescribing implementation details.
+
+## 12.1 Integration Definition Management
+
+open-reuse shall allow users to create, store, inspect, update, and version integration definitions.
+
+The product shall support:
+
+* Unique integration identity
+* Human-readable description
+* Upstream source references
+* Local repository references
+* Reuse mode classification
+* Maintainer assignment
+* Validation requirements
+* Update policies
+* Escalation rules
+* Lifecycle status
+
+## 12.2 Integration Registration
+
+open-reuse shall allow a structured integration definition to be registered with the open-reuse service.
+
+Registration shall result in:
+
+* The integration becoming visible in the registry
+* The integration being assigned a lifecycle state
+* Monitoring being activated according to policy
+* Maintainers becoming associated with escalation events
+* Validation requirements becoming available to automation
+
+## 12.3 Reuse Mode Classification
+
+open-reuse shall support explicit classification of the integration’s reuse mode.
+
+The classification should help determine:
+
+* Risk level
+* Recommended validation depth
+* Update automation eligibility
+* Escalation thresholds
+* Governance requirements
+
+## 12.4 Boundary Description
+
+open-reuse shall allow users to describe the boundary between local system and reused upstream asset.
+
+The boundary description should include:
+
+* Boundary type
+* Local interface or seam
+* Reused upstream surface
+* Expected compatibility assumptions
+* Known fragility points
+
+## 12.5 Upstream Monitoring
+
+open-reuse shall monitor relevant upstream sources.
+
+Supported upstream signals should include:
+
+* Releases
+* Tags
+* Commits
+* Dependency metadata
+* Changelogs
+* Security advisories
+* License changes
+* Repository archival status
+* Breaking-change indicators where available
+
+## 12.6 Change Impact Analysis
+
+open-reuse shall classify detected upstream changes according to their likely impact on registered integrations.
+
+Impact levels may include:
+
+* No relevant impact
+* Informational
+* Safe update candidate
+* Requires validation
+* Requires review
+* Blocking change
+* Unknown impact
+
+## 12.7 Update Handling
+
+open-reuse shall support controlled update handling based on update policies.
+
+Possible actions include:
+
+* Record change only
+* Trigger validation
+* Create update proposal
+* Create pull request
+* Apply transformation recipe
+* Request maintainer review
+* Block update
+* Escalate issue
+
+## 12.8 Validation Execution
+
+open-reuse shall integrate with validation mechanisms capable of proving whether the integration remains acceptable.
+
+Validation results shall include:
+
+* Pass/fail status
+* Check category
+* Execution timestamp
+* Upstream version tested
+* Local version tested
+* Error details where available
+* Required maintainer action if applicable
+
+## 12.9 Escalation Management
+
+open-reuse shall notify registered maintainers when human inspection is required.
+
+Escalations shall include:
+
+* Integration identity
+* Upstream change summary
+* Impact classification
+* Failed checks, if any
+* Recommended next action
+* Severity
+* Due or priority information where configured
+
+## 12.10 Audit Trail
+
+open-reuse shall preserve a traceable history of relevant events.
+
+The audit trail shall include:
+
+* Integration registration
+* Definition changes
+* Upstream changes detected
+* Impact analysis results
+* Validation results
+* Update attempts
+* Escalations
+* Maintainer decisions
+* Policy changes
+
+## 12.11 Dashboard and Reporting
+
+open-reuse shall provide visibility into the current state of registered integrations.
+
+The product should expose:
+
+* Healthy integrations
+* Integrations requiring review
+* Failed update attempts
+* Stale integrations
+* High-risk reuse modes
+* Unassigned maintainer cases
+* Security-sensitive escalations
+* Integration drift indicators
+
+---
+
+## 13. User Stories
+
+## 13.1 Register a Proven Integration
+
+As an integration maintainer,
+I want to register a proven integration with open-reuse,
+so that it can be monitored and maintained systematically.
+
+Acceptance expectations:
+
+* I can provide upstream source information.
+* I can classify the reuse mode.
+* I can identify local boundaries.
+* I can assign maintainers.
+* I can define validation requirements.
+* The integration appears in the registry.
+
+## 13.2 Classify Integration Risk
+
+As a platform engineer,
+I want open-reuse to classify integrations by reuse mode,
+so that high-risk reuse patterns can receive stronger validation and governance.
+
+Acceptance expectations:
+
+* Each integration has a reuse mode.
+* Risk level is visible.
+* Missing classification is treated as incomplete.
+* High-risk classifications can trigger stricter policy.
+
+## 13.3 Monitor Upstream Changes
+
+As an integration maintainer,
+I want open-reuse to detect relevant upstream changes,
+so that I do not need to manually watch every upstream project.
+
+Acceptance expectations:
+
+* Upstream versions are tracked.
+* New releases or changes are detected.
+* Relevant changes are associated with affected integrations.
+* Irrelevant changes can be ignored or classified as informational.
+
+## 13.4 Validate an Update
+
+As a maintainer,
+I want open-reuse to run validation after upstream change,
+so that I can trust whether the integration still works.
+
+Acceptance expectations:
+
+* Validation is linked to the integration definition.
+* Validation results are recorded.
+* Failed validation creates an actionable result.
+* Successful validation may allow automated continuation according to policy.
+
+## 13.5 Escalate a Breaking Change
+
+As a maintainer,
+I want to be notified when automation cannot safely handle a change,
+so that I can inspect and resolve the issue before production systems are harmed.
+
+Acceptance expectations:
+
+* Escalation includes reason and severity.
+* Escalation includes affected integration.
+* Escalation includes upstream change context.
+* Escalation identifies expected maintainer action.
+
+## 13.6 Inspect Integration Portfolio
+
+As a platform owner,
+I want to see all registered integrations and their health,
+so that I can manage open-source reuse as a portfolio of assets.
+
+Acceptance expectations:
+
+* Integrations are searchable.
+* Health status is visible.
+* Risk classification is visible.
+* Stale or failing integrations are highlighted.
+
+---
+
+## 14. Product Requirements
+
+## 14.1 Integration Definition Requirements
+
+The product shall provide a structured Integration Definition format.
+
+The format shall support at least:
+
+* Integration name
+* Description
+* Owner or maintainer
+* Upstream source
+* Local consuming system
+* Reuse mode
+* Reused surface
+* Local boundary
+* Current upstream version or reference
+* Update policy
+* Validation policy
+* Escalation policy
+* Lifecycle status
+
+## 14.2 Registry Requirements
+
+The product shall provide an integration registry.
+
+The registry shall support:
+
+* Registering integrations
+* Updating integration metadata
+* Listing integrations
+* Searching integrations
+* Filtering by status, owner, reuse mode, and risk level
+* Viewing integration details
+* Recording lifecycle state
+
+## 14.3 Monitoring Requirements
+
+The product shall detect upstream changes relevant to registered integrations.
+
+The product shall support configurable monitoring policies per integration.
+
+## 14.4 Policy Requirements
+
+The product shall allow users to define update and escalation policies.
+
+Policies shall distinguish between:
+
+* Safe automatic handling
+* Review-required handling
+* Blocked handling
+* Escalation-required handling
+
+## 14.5 Validation Requirements
+
+The product shall connect registered integrations to validation checks.
+
+Validation must be treated as a gate before updates are considered safe.
+
+## 14.6 Maintainer Requirements
+
+The product shall support assignment of maintainers to integrations.
+
+The product shall notify maintainers when escalation conditions occur.
+
+## 14.7 Traceability Requirements
+
+The product shall maintain a historical record of integration lifecycle events.
+
+Traceability shall be sufficient to answer:
+
+* What changed upstream?
+* Which integration was affected?
+* What was attempted automatically?
+* What validation ran?
+* What failed?
+* Who reviewed it?
+* What decision was made?
+
+---
+
+## 15. Non-Functional Requirements
+
+## 15.1 Reliability
+
+open-reuse shall be reliable enough to serve as a trusted maintenance coordination layer for important integrations.
+
+It shall avoid silent failures in monitoring, validation, and escalation.
+
+## 15.2 Transparency
+
+The product shall make automation decisions inspectable.
+
+Users should be able to understand why an update was accepted, blocked, or escalated.
+
+## 15.3 Extensibility
+
+The product shall support additional reuse modes, validation types, source providers, policy types, and notification channels over time.
+
+## 15.4 Security
+
+The product shall handle repository access, automation credentials, maintainer notification paths, and integration metadata securely.
+
+It shall avoid unnecessary access to source code or secrets.
+
+## 15.5 Auditability
+
+The product shall preserve enough historical information to support operational review, compliance review, and post-incident analysis.
+
+## 15.6 Portability
+
+The product should not depend on a single source control provider, CI provider, or package ecosystem as a conceptual requirement.
+
+## 15.7 Human Override
+
+The product shall allow maintainers to override automation outcomes where policy permits.
+
+## 15.8 Failure Containment
+
+The product shall fail safely.
+
+When it cannot classify, validate, or update confidently, it shall escalate rather than proceed silently.
+
+---
+
+## 16. Lifecycle States
+
+Registered integrations should support lifecycle states such as:
+
+| State        | Meaning                                                |
+| ------------ | ------------------------------------------------------ |
+| Draft        | Integration definition is being prepared               |
+| Registered   | Integration is known to open-reuse                     |
+| Active       | Integration is monitored and maintained                |
+| Needs Review | Human inspection is required                           |
+| Degraded     | Integration has unresolved validation or update issues |
+| Paused       | Automation is intentionally suspended                  |
+| Deprecated   | Integration should be replaced or removed              |
+| Retired      | Integration is no longer active                        |
+
+---
+
+## 17. Initial MVP Scope
+
+The MVP should prove that open-reuse can register and maintain a small number of valuable integrations in a structured, inspectable way.
+
+## 17.1 MVP Capabilities
+
+The MVP should include:
+
+1. Integration Definition Schema v0.1
+2. Git-based storage of integration definitions
+3. CLI or minimal service for registration
+4. Basic registry listing
+5. Manual or scheduled upstream version check
+6. Reuse mode classification
+7. Maintainer assignment
+8. Validation command definition
+9. Basic validation execution or integration with CI
+10. Status reporting
+11. Escalation output, at minimum as issue creation or notification
+12. Audit log of key lifecycle events
+
+## 17.2 MVP Reuse Modes
+
+The MVP should initially support:
+
+* Dependency reuse
+* Adapter reuse
+* Component extraction
+* Patch overlay
+
+Plugin reuse and fork continuation may be modeled but do not need full automation in the first MVP.
+
+## 17.3 MVP Success Scenario
+
+A team has a working integration with an upstream open-source project.
+
+They create an open-reuse Integration Definition, register it, configure an upstream version source, define validation commands, and assign maintainers.
+
+When upstream changes, open-reuse detects the change, records it, triggers validation, and reports whether the integration remains healthy.
+
+If validation fails, open-reuse creates an escalation for the registered maintainer.
+
+---
+
+## 18. Future Scope
+
+Future versions may include:
+
+* Web dashboard
+* Deeper source-code impact analysis
+* AI-assisted integration analysis
+* AI-assisted reuse mode classification
+* AI-assisted refactoring recommendations
+* Transformation recipes
+* Codemod integration
+* Semantic API compatibility analysis
+* License-change detection
+* Security advisory integration
+* Pull request generation
+* Auto-merge for low-risk updates
+* Organizational policy packs
+* Integration health scoring
+* Multi-repository portfolio analytics
+* Integration drift metrics
+* Maintainer workload tracking
+* Open-source contribution recommendations
+* Upstream collaboration workflows
+
+---
+
+## 19. Success Metrics
+
+open-reuse success should be measured by operational outcomes.
+
+Potential metrics:
+
+| Metric                              | Meaning                                                   |
+| ----------------------------------- | --------------------------------------------------------- |
+| Registered integrations             | Number of integrations managed by open-reuse              |
+| Classified integrations             | Percentage with explicit reuse mode                       |
+| Boundary-defined integrations       | Percentage with explicit local boundary                   |
+| Automated update checks             | Number of upstream checks executed                        |
+| Validation coverage                 | Percentage with configured validation harness             |
+| Escalation precision                | Percentage of escalations that required real human action |
+| Mean time to detect upstream change | Time from upstream change to open-reuse detection         |
+| Mean time to validate update        | Time from detection to validation result                  |
+| Failed silent updates               | Should trend toward zero                                  |
+| Integration drift                   | Difference between tracked and current upstream state     |
+| Maintainer response time            | Time from escalation to review                            |
+| Manual maintenance reduction        | Reduction in ad-hoc update work                           |
+
+---
+
+## 20. Risks and Mitigations
+
+## 20.1 Risk: Scope Becomes Too Broad
+
+open-reuse could become a generic integration platform, dependency manager, CI system, or security tool.
+
+Mitigation:
+
+* Keep focus on post-success integration continuity.
+* Integrate with existing tools rather than replacing them.
+* Treat Integration Definition as the core product asset.
+
+## 20.2 Risk: Automation Is Overtrusted
+
+Users may assume open-reuse can safely resolve all upstream changes.
+
+Mitigation:
+
+* Default to escalation for uncertainty.
+* Make confidence levels visible.
+* Require validation before update acceptance.
+* Avoid unsafe auto-merge defaults.
+
+## 20.3 Risk: Definitions Become Documentation Only
+
+Integration definitions could become stale if not connected to automation.
+
+Mitigation:
+
+* Treat definitions as executable configuration.
+* Validate definitions regularly.
+* Report stale or incomplete definitions.
+
+## 20.4 Risk: High Setup Cost
+
+Teams may resist writing structured integration definitions.
+
+Mitigation:
+
+* Provide templates.
+* Support incremental adoption.
+* Add analysis helpers.
+* Allow draft definitions.
+* Start with minimal required fields.
+
+## 20.5 Risk: Hard-to-Classify Integrations
+
+Real integrations may combine multiple reuse modes.
+
+Mitigation:
+
+* Allow composite reuse modes.
+* Support primary and secondary classification.
+* Permit unknown or transitional states with review.
+
+## 20.6 Risk: Maintainer Fatigue
+
+Too many escalations may reduce trust in the system.
+
+Mitigation:
+
+* Tune escalation thresholds.
+* Group related alerts.
+* Distinguish informational events from required actions.
+* Improve impact analysis over time.
+
+---
+
+## 21. Assumptions
+
+The PRD assumes:
+
+* Integrations are stored or described in version-controlled environments.
+* Teams can provide at least minimal validation commands.
+* Maintainers can be assigned to integration assets.
+* Upstream sources expose detectable change signals.
+* The first version may rely on existing CI, source control, and notification systems.
+* Fully automated remediation is not required for product value.
+
+---
+
+## 22. Dependencies
+
+open-reuse may depend on or integrate with:
+
+* Git repositories
+* Source control providers
+* CI/CD systems
+* Package registries
+* Container registries
+* Dependency update tools
+* Security advisory sources
+* License scanning tools
+* Issue trackers
+* Notification systems
+* Code transformation tools
+* AI coding or analysis agents
+
+These dependencies are external capabilities, not necessarily built into open-reuse itself.
+
+---
+
+## 23. Open Questions
+
+1. Should the first implementation be CLI-first, service-first, or GitHub/GitLab-app-first?
+2. Should the Integration Definition Schema be YAML, JSON, CUE, Jsonnet, or another structured format?
+3. Should open-reuse maintain its own registry database, or should git remain the source of truth?
+4. What is the minimal validation model for MVP?
+5. How should maintainers be represented: users, teams, roles, or external identities?
+6. Should open-reuse distinguish technical maintainers, business owners, security owners, and legal reviewers?
+7. Should integration definitions live in the consuming repository, a central registry repository, or both?
+8. How strongly should open-reuse integrate with dependency update tools?
+9. How should composite reuse modes be represented?
+10. What is the first real-world integration to use as reference case?
+
+---
+
+## 24. Acceptance Criteria for PRD v0.1
+
+This PRD is acceptable if it enables the next artifacts to be created:
+
+* Integration Definition Schema v0.1
+* Functional Requirements Specification
+* MVP architecture outline
+* Use Case Catalog
+* Initial CLI/service design
+* Example integration definition
+* Repository structure proposal
+
+---
+
+## 25. Product Positioning
+
+open-reuse occupies the space between:
+
+* Package management
+* CI/CD
+* Dependency update automation
+* Software composition analysis
+* Source control
+* Integration architecture
+* Maintainer governance
+
+Its unique position is the structured lifecycle of **valuable reuse under upstream change**.
+
+The shortest positioning phrase is:
+
+> **open-reuse starts after “it works” and before “it becomes technical debt.”**
+
+