A202

Form an agreement between two parties who already know each other, with no marketplace and no negotiation room. Call this once per transaction. Both parties present the allow decision their own mandate produced. The offeror verifies {"action_type": "offer.submit", "transaction_id": ..., "counterparty_organization_id": <the offeree's org>, "proposed_terms": <the same terms>} and the offeree verifies the same document with action_type offer.accept and the offeror's organisation. Pass each result as buyer_decision and supplier_decision. A decision over a different act, a different mandate, or an amount the mandate did not allow refuses the whole call and records nothing. It writes the whole formation in one call: the offeror's signed offer carrying a session identifier it mints, the offeree's acceptance over the exact offer hash, the agreement carrying both parties' signatures over the same bytes, the supplier's commitment, and two events, agreement.direct (draft to agreement_pending) and agreement.committed (agreement_pending to committed), each countersigned by the other party. The transaction ends this call in state committed. Follow with record_obligation act=issue. Refusals: a transaction that already left draft (A202-STATE-TRANSITION-DENIED), an unregistered profile (A202-PROFILE-UNKNOWN), terms the profile does not allow (A202-PROFILE-TERMS-INVALID), an offer expiring before it was made (A202-OFFER-EXPIRED).

Return this party's own copy of the hash-chained transaction record: every event in chain order with the state it moved the transaction to, which keys signed it, and the object it concerns, plus the state the record currently reaches and every object identifier held for the transaction. Call it at any point to see where a transaction stands before deciding what to do next. Ordering is by predecessor reference rather than by a counter, because bilaterally there is no ordering service, and a record whose links do not form one chain is reported as broken with A202-EVIDENCE-CHAIN-GAP.

Record a named principal's approval of one exact act, bound to the action_hash verify_mandate reported. Call this only after verify_mandate answered require_approval, then call verify_mandate again passing approval_id and the identical proposed_action. The approval is signed by the approving principal's own key, not by the agent's, because the control is that somebody other than the acting agent said yes. It binds one action hash and one transaction and is reusable across neither: change one byte of the act and the next verify_mandate returns A202-APPROVAL-HASH-MISMATCH. It also expires, after which it authorises nothing. An approval never releases a deny. A denied constraint is a limit, not a question. Returns the approval identifier, the action hash it binds, and when it expires.

Issue and sign a commercial mandate: the document stating which organisation an agent represents, which acts it may take, under which limits, for which transaction or category, and for how long. Call this once per acting agent before anything else. Every other tool names the mandate an agent acts under. A spending_limit becomes two explicit constraints, an amount ceiling and a currency, both visible in the audit record. The mandate is checked before it is signed, so a refused one never receives a signature that would make it look issued. Refusals: no constraint at all (A202-MANDATE-UNBOUNDED), a scope naming neither a transaction nor a category (A202-MANDATE-SCOPE-TOO-BROAD), an inverted validity interval (A202-MANDATE-INTERVAL-INVALID), a status endpoint that is not HTTPS (A202-MANDATE-STATUS-INSECURE), a subject naming both an agent and a principal (A202-MANDATE-SUBJECT-AMBIGUOUS). Returns the mandate identifier and the signed document.

Record one act in the obligation exchange. Three acts, in this order, each signed by a different party, and each carrying that party's own allow decision from verify_mandate. act=issue: the obligee derives an obligation from a committed agreement and activates it. Needs agreement_id, obligor, obligee, term_path, quantity, unit_code, due_condition, and a decision the obligee obtained for {"action_type": "obligation.activated", "transaction_id": ..., "counterparty_organization_id": <the obligor's org>, "proposed_terms": {"core": {"quantity": ..., "unit_code": ..., "total": <the consideration>}}, "agreement_id": ...}. The transaction moves to in_performance. act=assert: the obligor asserts it performed. Needs obligation_id, obligor, obligee, asserted_quantity, at least one evidence entry, and a decision the obligor obtained for action_type performance.declared naming the obligee as counterparty, the asserted quantity and unit as proposed_terms, and the obligation_id. An assertion with no evidence is refused with A202-OBLIGATION-ASSERTION-UNEVIDENCED. The transaction moves to acceptance_pending. act=respond: the obligee accepts or rejects, bound to the exact assertion hash. Needs assertion_id, responder, counterparty, response_type, and a decision the responder obtained for action_type acceptance.granted or acceptance.rejected naming the counterparty and the assertion_id. A response signed by anyone but the obligee is refused with A202-OBLIGATION-RESPONSE-UNAUTHORIZED; accepting less than is owed without naming a remainder obligation is refused with A202-OBLIGATION-REMAINDER-MISSING. Accept moves the transaction to settlement_pending, reject back to in_performance, where the obligor may assert again.

Run the seven-step verification procedure over a set of objects: content hashes, signatures and the purpose each was issued for, version chains, event-chain continuity, guarded transitions replayed against the rules version in force, whether each determination follows from its rules, and what could not be checked. Use it on your own record before relying on it, and on anything a counterparty sends you. Pass transaction_id to verify this server's record of one transaction, object_ids to verify part of it, or objects to verify a bundle somebody handed you. Every check returns verified, failed, or not_checkable, and the result carries no overall boolean, because a report reduced to one discards what could not be checked. A signature whose key you do not hold is not checkable and is never thereby verified. Without rules_version, guarded transitions are not checkable rather than verified: an unresolvable rule set is not permission in either direction.

Check a mandate and decide whether an act is permitted under it. Call this before every act, on your own mandate or on one a counterparty presented. It checks the document against the published schema and the rules the schema cannot express, verifies the issuer signature, checks the validity interval, and, when proposed_action is given, checks the act against the mandate's actions, its four scope axes, its constraints in stable order, and its approval rules. Returns one decision, allow, deny, or require_approval, with the registered reason codes behind it, the per-constraint outcomes, and action_hash, the hash of the exact act evaluated. On require_approval: pass that action_hash to issue_approval, then call this tool again with the returned approval_id and the identical proposed_action. The decision becomes allow. A deny is never approvable. This server makes no network call. Resolve the mandate's status_endpoint yourself and pass the result as status. An absent result, one older than 60 seconds, or any status other than active denies with A202-MANDATE-STATUS-UNRESOLVED or A202-MANDATE-INACTIVE: unavailability is not permission.