# Principles that guide the work

Mpalo’s mission and ground principles provide the reason and constraints for every design decision.

HTML page: https://developer.mpalo.com/principles
Markdown page: https://developer.mpalo.com/principles.md

## Navigate sections

- [Mission](principles#mission)
- [Design principles](principles#design-principles)
- [Proof and uncertainty](principles#proof-and-uncertainty)
- [Decision test](principles#decision-test)

## The mission is the design brief

Mpalo exists to maximize humanity’s capacity for autonomous, informed, and constructive decision-making. Interface decisions should increase a person’s capacity to understand and act, not quietly make the decision for them.

The mission describes the enduring purpose. Products, tools, and visual expressions are ways of pursuing it, and may change as the work changes.

[Read the full mission](https://mpalo.com/our-mission)

## Principles for making decisions

These working principles translate Mpalo’s doctrine into questions that can guide a page, control, or interaction.

- **Purpose**: What human need does this serve? Remove elements that do not help meet it.

- **Agency**: Can people understand what is happening, choose their path, and recover from mistakes?

- **Responsibility**: Does the experience protect people’s information and make consequential behavior clear?

- **Honesty**: Does the interface distinguish what is true now from what is intended, uncertain, or unavailable?

- **Simplicity**: Can the same task be made clearer without hiding meaningful choices or context?

- **Craft**: Does each detail work well, read clearly, and hold up across devices and input methods?

- **Humanity and nature**: Does the expression keep human beings, animals, nature, and culture within the circle of concern, without claiming to serve beyond what Mpalo can support?

## Ground claims in evidence

Mpalo’s ground principle requires claims to be based on observable, verified truth. If something is unknown or unverified, document the gap. A polished presentation must never make a capability look more complete or certain than it is.

For interface documentation, label whether a behavior is current, in development, planned, or not deployed. Keep the status in words and point to evidence when available.

## Before a design decision is accepted

1. What purpose does it serve?
2. Which domain and audience is it for?
3. What does it let a person understand or do?
4. What evidence shows it works as intended?
5. Can the decision be expressed in a shared token, component, or documented pattern?

## Related pages

- [One institution, distinct domains](domains.md)
- [The parts we can govern](elements.md)
- [How the pieces connect](map.md)

## Authoritative integration reference

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