feat: add draft data, gap analysis report, and workspace config

workspace/draft-team/cycles/dynamic-trust-and-reputation/20-architecture-brief.md

@@ -0,0 +1,113 @@
+# Architecture Brief
+
+## Scope
+
+Define an experimental, interoperable representation for dynamic trust information exchanged between agents or agent-adjacent services. The draft should standardize:
+
+- trust event vocabulary
+- trust assertion envelope
+- issuer, subject, scope, freshness, and confidence semantics
+- expiry or revocation behavior
+- minimal rules for how receivers interpret portable trust information
+
+The document should remain supplemental to identity, attestation, and authorization systems.
+
+## Non-goals
+
+- creating a global reputation network or universal score
+- replacing authentication, attestation, or authorization
+- standardizing all behavior-verification evidence formats
+- requiring a single scoring algorithm
+- defining economic incentives, penalties, or marketplace reputation
+
+## Terminology and actors
+
+- `trust event`: an observed runtime occurrence relevant to trust assessment
+- `trust assertion`: a structured statement by an issuer about a subject's trust-relevant state
+- `issuer`: the party making the assertion
+- `subject`: the agent or service described by the assertion
+- `confidence`: how strongly the issuer stands behind the assertion
+- `freshness`: how current the assertion is and how long it remains usable
+- `scope`: the context in which the assertion is intended to apply
+- `evidence reference`: pointer to supporting execution, attestation, or compliance evidence
+- `revocation`: withdrawal or supersession of a prior trust assertion
+
+Actors:
+
+- observing agent or service
+- trust assertion issuer
+- relying party that consumes trust information
+- optional policy authority governing how trust affects decisions
+
+## Protocol or data model shape
+
+Use two related objects:
+
+1. a trust event record
+2. a trust assertion
+
+Trust event record minimum fields:
+
+- event identifier
+- subject identifier
+- issuer or observer identifier
+- event type
+- timestamp
+- scope
+
+Trust assertion minimum fields:
+
+- assertion identifier
+- subject identifier
+- issuer identifier
+- trust statement value
+- confidence value
+- freshness or expiry information
+- scope
+
+Optional fields:
+
+- evidence reference
+- delta-from-prior assertion
+- revokes or supersedes assertion identifier
+- explanation code
+
+Design choice: do not require one numeric scoring model. Allow bounded levels, numeric values, or deltas as long as the representation states which model is being used and how confidence and expiry apply.
+
+## Normative requirements candidates
+
+- A trust assertion MUST identify both issuer and subject.
+- A trust assertion MUST indicate scope and freshness.
+- A trust assertion MUST NOT be treated as a substitute for authentication or authorization.
+- If a trust assertion supersedes or revokes a prior assertion, it MUST identify the prior assertion.
+- Receivers MUST be able to distinguish portable trust assertions from local-only trust state.
+- Trust assertions SHOULD include evidence references when the underlying evidence is available and shareable.
+- Implementations SHOULD define local policy for how negative assertions are consumed; this document should not hardcode one response.
+- Issuers MUST NOT present stale assertions as current.
+
+## Security, privacy, and abuse considerations
+
+- false negative or false positive trust assertions can manipulate routing or authorization decisions
+- colluding issuers could amplify reputational poisoning
+- replayed stale assertions can preserve obsolete trust
+- over-shared negative trust information can leak sensitive incident details
+- portable trust data may be misread as global truth rather than scoped issuer opinion
+
+The draft should strongly emphasize that trust assertions are context-bound statements requiring authenticated origin, explicit freshness, and local policy interpretation.
+
+## IANA impact
+
+Potentially small registries only if needed by implementation experience:
+
+- trust event types
+- trust assertion statement models
+- explanation codes
+
+Avoid large registries or score semantics that imply false precision.
+
+## Open design questions
+
+- Should the primary trust statement model be level-based, numeric, delta-based, or model-agnostic?
+- How much explanation should be mandatory when sharing negative trust?
+- How should a receiver compare assertions from different issuers with different confidence models?
+- Should revocation be a first-class assertion type or simply a superseding assertion?