Port develop->main: architectural-principles.md with Principle 5 + authority rules
This commit is contained in:
@@ -0,0 +1,53 @@
|
|||||||
|
# Architectural Principles
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principle 1: Mission Scope And Contract Scope Are Separate
|
||||||
|
|
||||||
|
The company may identify any digital issue that affects customer acquisition, visibility, trust, or conversion.
|
||||||
|
|
||||||
|
The recurring service only includes monitoring, diagnosis, prioritization, reporting, and approved low-risk optimizations.
|
||||||
|
|
||||||
|
Any work outside the defined recurring service areas is treated as a separate project unless explicitly included in the client's package.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principle 2: AI Visibility Is Core, But AI Placement Is Not Guaranteed
|
||||||
|
|
||||||
|
The company may monitor and improve the digital signals that help AI-assisted discovery systems understand and represent a business.
|
||||||
|
|
||||||
|
The company does not guarantee that any AI system will recommend, rank, cite, or surface a client in response to any specific query.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principle 3: Reports Are Receipts, Not The Product
|
||||||
|
|
||||||
|
The product is continuous digital oversight and optimization.
|
||||||
|
|
||||||
|
Reports exist to document what was monitored, what was found, what was improved, what remains at risk, and what is recommended next.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principle 4: The Company Improves Digital Pathways, Not Every Marketing Function
|
||||||
|
|
||||||
|
The company focuses on the digital pathways that turn customer interest into customer action.
|
||||||
|
|
||||||
|
The company does not become a general-purpose marketing agency by default.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Principle 5: Verified Evidence And Indicative Evidence Must Be Separated
|
||||||
|
|
||||||
|
The company distinguishes between verified defects and indicative risks.
|
||||||
|
|
||||||
|
Verified defects may be presented as confirmed issues when supported by concrete evidence.
|
||||||
|
|
||||||
|
Indicative risks must be presented as directional evidence, not proven customer loss.
|
||||||
|
|
||||||
|
This distinction protects client trust, prevents overclaiming, and keeps reports credible.
|
||||||
|
|
||||||
|
Agents may propose evidence classifications, but humans approve final evidence tiers before client-facing use during Version 1.
|
||||||
|
|
||||||
|
Ambiguous findings default to Indicative Evidence unless upgraded by human review.
|
||||||
|
|
||||||
|
Rejected Verified Evidence classifications default to Indicative Evidence unless the reviewer discards the finding or requests additional evidence.
|
||||||
Reference in New Issue
Block a user