System Characteristics

System characteristics describe how a well-designed autonomous system should operate. They improve reliability, adaptability, and efficiency, but they are not automatically part of the unit’s constitutional mandate.

This distinguishes them from Axioms. An axiom is an installed invariant that every action must preserve. A characteristic is an architectural recommendation. Founders may choose to elevate a characteristic into an axiom, but that requires an explicit constitutional decision.

Recoverability and human administration

Humans should retain a practical way to inspect, pause, administer, and recover the system after a serious failure. Automation should not eliminate the escape hatches needed to restore service, revoke access, reconstruct state, or take over a failed process.

Recoverability is a characteristic because it concerns how the system is designed and operated. A particular unit may separately install a binding axiom requiring human recovery paths to remain available.

Flexibility

The architecture should remain adaptable as models, research, providers, and operating conditions change. It should avoid unnecessary dependence on one model or inference provider and preserve a path for replacing components whose capabilities or availability no longer meet the unit’s needs.

Flexibility supports continuity and competitive adaptation. It is not inherently an axiom: a unit may legitimately accept a deliberate dependency or fixed technology choice when its constitution permits that trade-off.

Telemetry, observability, and self-inspection

The unit should produce enough telemetry to diagnose failures, evaluate outcomes, and understand its own operating condition. Agents responsible for operation and improvement should be able to access authorised traces, metrics, costs, decisions, and recovery events rather than depending entirely on human interpretation.

Observability makes verification and learning possible. A binding obligation to retain particular evidence belongs in a provenance axiom or policy; the general ability to observe the system remains an architectural characteristic.

Progressive operationalization

The system should use capable models when it encounters uncertain or unfamiliar work, then convert recurring solutions into implementation artifacts, tools, skills, evaluations, and deterministic workflows. This prevents the unit from repeatedly paying for open-ended reasoning after a process becomes understood.

This is a recommended optimization strategy, not a universal constitutional constraint. A unit’s goals, risk profile, or economics may justify a different balance between frontier reasoning and deterministic execution.

When a characteristic becomes an axiom

Founders may decide that a characteristic is important enough to become binding. The wording must then change from a preference into an invariant with scope, evidence, enforcement, and amendment rules.

Characteristic	Possible installed axiom
Prefer recoverability	The unit must not remove the last authorised human recovery path.
Prefer provider flexibility	The unit must preserve an operational failover for every dependency classified as continuity-critical.
Prefer observability	Every consequential action must emit the evidence required by the installed provenance contract.
Prefer operationalization	A recurring process above the defined cost threshold must enter an optimization review.

The characteristic remains general design advice. The right-hand statement becomes an axiom only when an authorised founder or constitutional process installs it into a particular unit.

Related concepts

• Axioms - Defines the binding invariants installed into the unit.
• Autonomous Business Unit - Defines the unit’s business identity and operating loop.
• Controls & Autonomy - Applies structural controls according to action risk.
• Minimal Bootstrap - Defines the architectural conditions required for sustained autonomous operation.