shared/expert-system/product-quality-principles.md

# Claus Argos — Product Quality Principles

This is the canonical cross-project quality lens for product, interface, implementation, specification and verification work. It complements—not replaces—decision authority, approved project truth, specialist standards, measurable acceptance and risk-adaptive assurance. Apply only the questions material to the current scope; it is not an eight-checklist ritual and creates no new approval authority.

## Operational principles

- **PURPOSE:** Which real user or business job does the feature, interface or experience serve? Does each material element justify its existence? Remove or challenge work that has no approved outcome, without erasing purposeful complexity.
- **AGENCY:** Can people understand what will happen and remain in control? Where appropriate, can they refuse, leave, cancel, undo, recover or choose another path? Consequential actions require clear effect, proportionate confirmation and a recoverable or explicitly irreversible boundary.
- **RESPONSIBILITY:** What privacy, security, AI, misuse, failure and harmful-outcome risks are material? Are safeguards proportionate, observable and tested? Collect or expose only necessary data; prefer local handling when it satisfies the approved need; make purpose and control understandable.
- **FAMILIARITY:** Are common actions predictable where established behavior helps understanding and confidence? Keep language, feedback and interaction internally consistent. Familiarity does not authorize copying another brand or suppressing approved Claus Argos differentiation.
- **FLEXIBILITY:** Does the outcome work across the actually supported devices, viewports, inputs, abilities, experience levels, locales and use contexts? Do not claim universal support; define and test the relevant range.
- **SIMPLICITY:** Has avoidable friction, duplication and cognitive burden been removed? Simplicity is not visual minimalism. Preserve purposeful complexity when the task, domain, differentiation or control model requires it.
- **CRAFT:** Are typography, geometry, hierarchy, alignment, states, feedback, motion, responsiveness, accessibility, performance, edge cases, recovery and failure behavior intentionally finished at the required level? Technical completion and perceptual completion remain separate gates.
- **DELIGHT:** Does satisfaction emerge from clarity, control, responsiveness, beauty, confidence, thoughtful detail and approved emotional intent? Gimmicks, spectacle and novelty do not compensate for weak purpose, agency or reliability.

## Contextual quality gates

Activate these only when the product scope makes them material. An inapplicable gate needs no ceremonial artifact.

### Privacy and responsibility

Ask: Is the data necessary? Why is it required? Can it remain local? Does the person expect this use? Can they control it? What are credible failure, abuse and harmful-outcome cases? Route deep security, privacy, legal or compliance work to the appropriate specialist; this contract does not certify them.

### Global and localization readiness

Where relevant, define and test text expansion and contraction, plurals, dates, numbers, currencies, right-to-left layout, flexible geometry, cultural adaptation and supported locale variants. Architecture readiness does not imply that translations already exist.

### Search and discoverability

Where search is material, check that its surface and scope are understandable, suggestions and result grouping are useful, history respects privacy, and important content remains discoverable without clutter. Search mechanics and SEO require their own applicable evidence.

### Product longevity and maintenance

Where lifespan and change rate warrant it, define triggers for dependency or platform change, design-system evolution, accessibility or performance regression, security review, AI-evaluation refresh and source/method freshness. Do not create recurring review bureaucracy without a named risk, owner, evidence need and action threshold.

## Use and boundaries

1. Establish approved purpose, scope, audience, supported contexts and authority before applying the principles.
2. Turn material principles into requirements, observables, acceptance criteria or specialist routes; do not award PASS from principle wording alone.
3. Mark non-applicable questions briefly when their omission could otherwise be mistaken for an oversight.
4. Preserve stronger project-specific requirements and existing governance. This contract never reopens `METHOD_CLOSED`, overrides owner decisions or changes product, brand, architecture, security, compliance or release authority.
5. Use external reference products only for transferable method evidence. Do not import Apple visual styling, symbols, typography, radii, spacing, navigation placement, animation curves, platform components or implementation techniques into unrelated work.