How this package was signed
===========================

Two signatures, two scopes, because they are two different claims:

  issuer seal    covers the MEASUREMENT VIEW: origin, integrity, and
                 well-formedness. It excludes the decision layer by
                 construction, so it survives a decision arriving later.
                 It is not a review and not an acceptance decision.

  decision       signed by the demonstration reviewer identity, a
                 labeled fixture rather than a person standing behind
                 this model. In production the same route carries the
                 reviewing engineer's own key, and only then is the
                 signature a commitment.

  package hash   sha256:f8877325516a2d53e3830e241c1b4db07e07b6ab90a370f7c0fe81e15d45ff5b

Check it yourself, with the published wheel and nothing from this app:

  pip install uofa
  uofa verify uofa.jsonld \
      --pubkey keys/uofa-issuer.pub \
      --decision-pubkey keys/demo-reviewer.pub

verify names the anchor it checked against and reports the two scopes
separately. Different keys read as 'independent attestation'; one key
across both reads as 'single-party configuration'. It is derived from
key identity, never key count, so the stronger claim cannot be faked.

What the shipped anchors do and do not establish
------------------------------------------------

The public keys travel inside this zip, so the package is SELF-CONSISTENT
without fetching anything: you can check that these keys signed these
bytes, and that nothing has changed since.

They do NOT bind either key to a real-world party. That is custody's job,
and it is a different question with a different answer for every
deployment. Here both identities are labeled demonstration fixtures, so
the question does not arise; in a production deployment the reviewer key
belongs to a named engineer and binding it to them is the operator's
responsibility, not this file's.
