# Commercial agreement, legal-entity, and signatory checklist

**Not legal advice.** This is an evidence checklist, not an agreement and not a
statement that an entity exists, insurance is held, counsel approved, a person
has authority, or a partner accepted.

## Organization evidence

- [ ] Exact legal entity name, entity type, jurisdiction, registration number,
  registered address, good-standing evidence, and tax/payment details verified.
- [ ] Contracting counterparty and notice address verified.
- [ ] Authorized signatory's name/title and authority evidence verified,
  including limits or required board/member approvals.
- [ ] Beneficial ownership, sanctions/KYC, procurement, or vendor records
  completed where applicable by authorized teams.
- [ ] Insurance requirements decided; certificates/limits/exclusions reviewed.
- [ ] Counsel and privacy reviewers identified and their written signoffs bound
  to the exact candidate and agreement version.

## Agreement readiness

- [ ] Parties, purpose, scope, candidate, pilot term, success/acceptance tests,
  fees/taxes, support tier, change process, and bounded exit are complete.
- [ ] Security, vulnerability reporting, incident escalation, data map,
  retention, confidentiality, IP, publicity, liability, indemnity, warranties,
  governing law, dispute terms, and insurance are addressed.
- [ ] The five organizational commitments are included without an SLA or order
  form overriding them.
- [ ] Signature blocks, dates, authority representations, counterpart/e-sign
  mechanics, order of precedence, and complete exhibits are reviewed.
- [ ] Both parties' authorized signatures and explicit partner acceptance are
  retained in the approved system of record.

## Fail-closed result

Any unchecked item remains an external human blocker. Repository documentation
cannot form an entity, appoint a role, buy insurance, provide counsel/privacy
approval, establish signatory authority, accept for a partner, or execute an
agreement. Do not store unredacted identity, tax, signature, or insurance
documents in a public repository; use a redacted evidence attestation with
digest and controlled-system reference.
# Independent legal-entity verification

For each contracting organization, collect—but do not invent—the exact legal
name, jurisdiction, registration reference, active status, registry/provider
identity, verification timestamp and expiry, registry-response digest, and a
detached signature from the independently pinned authority. The signed trusted
registry must bind the organization ID to the verification file’s exact
external path and SHA-256 digest.

An internal reviewer’s assertion is not proof that an entity exists. A
commercial agreement cannot pass merely because it contains a plausible name,
an organization identifier, or `entityVerified=true`. The agreement’s two
normalized legal names must exactly match the two independently verified
registry records.

The checked-in package contains no such evidence and makes no claim of entity
formation, signatory authority, counsel approval, partner acceptance, or legal
advice.

The legal-registry authority must be separate from the human-identity
authority. A future reviewed commit must pin its exact external root path,
root ID, issuer ID, public-key digest, and authority class. Each legal-entity
verification must resolve a distinct registry response outside the repository;
the checker validates the response's signature, issuer authority, exact entity
fields, active status, query reference, issuance/observation/expiry ordering,
and 30-day freshness. The current legal-registry policy is intentionally
disabled, and no registry response or legal entity is claimed.
