# No-Go’s

A direct reference for design choices Mpalo should not make, grounded in institutional truth, human agency, and domain boundaries.

HTML page: https://developer.mpalo.com/no-gos
Markdown page: https://developer.mpalo.com/no-gos.md

## Navigate sections

- [Truth and capability](no-gos#truth-and-capability)
- [Agency and care](no-gos#agency-and-care)
- [Visual anti-patterns](no-gos#visual-anti-patterns)
- [Domain misuse](no-gos#domain-misuse)

## Do not make a claim look more certain than it is

Mpalo’s ground principle is observable truth. Unknown, unverified, planned, and unavailable behavior must remain distinguishable from current capability.

- Do not fabricate facts, measurements, implementation status, evidence, or product outcomes.
- Do not present a planned, research, mock, or contract-stage capability as live behavior.
- Do not use polish, animation, or confident wording to hide uncertainty or missing evidence.
- Do not imply a user’s identity, memory, or agency is represented more completely than the system can support.

## Do not take meaningful control away from people

- Do not disguise consequential choices, make recovery unnecessarily difficult, or make a guided path impossible to leave.
- Do not use urgency, shame, or ambiguity to push a person toward an action.
- Do not collect or request information without explaining its purpose at the point it matters.
- Do not make essential information or actions depend only on color, hover, sound, animation, or pointer use.

## Do not add visual structure without a reason

Every visual element needs a job. Use spacing, alignment, and surface color to establish hierarchy before adding lines or decoration.

- Do not wrap ordinary content in cards just to make it look organized.
- Never use a left-border badge, side stripe, or badge card to label ordinary content. This pattern is a design No-Go. When order matters, use a typographic number beside its content without a box, background, border, or badge container.
- Do not add borders or separators as a default. Add one only when it carries necessary grouping or interaction information.
- Do not use an icon where a clear text label is needed, or repeat decorative icons beside every navigation item.
- Do not use a color, font, token, or component outside its documented domain role without recording why.

## Do not flatten the domain hierarchy

- Do not make public Mpalo feel like a terminal or make expert tools read like marketing pages.
- Do not copy a domain’s palette or component behavior into another domain by default.
- Do not let technical density remove human context, or let humanist expression make a technical contract imprecise.
- Do not present internal or access-controlled material as public developer guidance.

When a proposed design seems to require a no-go, pause and document the user need, evidence, domain, and least harmful alternative before changing the guidance.

## Related pages

- [Principles that guide the work](principles.md)
- [One institution, distinct domains](domains.md)
- [The parts we can govern](elements.md)

## Authoritative integration reference

- [API quickstart](https://api.mpalo.com/get-started)
- [API reference](https://api.mpalo.com/landing)