Aries Tools Architecture

Authority. This skill is maintained only in ariestools/ariestools-skills; edit there, not in installed copies. It records the shared architectural preference for adopting Aries Tools and XYO projects. The user's instructions and the repository's accepted protocol and decisions govern a particular task. Preserve existing contracts and scope; propose an architectural amendment when needed rather than silently redesigning a system.

Skill identity. When reporting which skills informed the work, use ariestools-architecture v<version> from this file's metadata.version.

Default. Prefer autonomous, replaceable participants whose protocol-defined behavior produces useful work through independently verifiable state transitions and reconciliation. Participants discover eligible work, tolerate concurrent attempts and worker disappearance, and recover from durable evidence. Introduce coordination where a named correctness invariant or resource constraint requires it, and confine its authority to that requirement.

Scope. This is a tool-independent design policy, with no required SDK, blockchain, gossip transport, or deployment topology. Here, a protocol is the explicit set of rules governing eligibility, authorization, valid outcomes, conflicts, and recovery. A local process supervisor can manage startup, shutdown, and resources while application work remains autonomous. Distinguish that lifecycle responsibility from authority over which business operation happens next.

Applying the preference

Before selecting a controller or worker topology, identify the operation, its authoritative evidence, its acceptance rules, and the conditions needed for progress. Describe how an eligible worker independently discovers outstanding work and how another participant resumes after it disappears. Read principles.md for the design defaults.

Use review.md when comparing architectures, introducing concentrated authority, reviewing a design, or writing architecture acceptance criteria. Explain any coordination through its invariant or resource constraint, authority scope, failure behavior, recovery path, and verification. This explanation is an engineering requirement; it does not create an additional approval gate.

Scale the review to the decision. A new distributed protocol needs its trust and failure assumptions stated; a small change to one established worker may need only the affected concurrency or recovery criterion. Do not apply swarm machinery to ordinary local computations or rewrite an accepted architecture during unrelated maintenance.

References