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

workspace/draft-team/cycles/dynamic-trust-and-reputation/50-reviews-v1/architecture.md

@@ -0,0 +1,24 @@
+# Architecture Review
+
+## Findings
+
+### Medium: scope discipline is good, but the draft risks under-specifying the portable core
+
+The draft correctly avoids becoming a universal reputation system. The remaining risk is that so much is left to local policy that the portable assertion core becomes too thin. The architecture should define a firmer minimum portable envelope.
+
+### Medium: the trust-event object may be more than the first revision needs
+
+The draft has both trust events and trust assertions. That layering is sensible, but the architecture should say more directly whether trust-event interoperability is a primary goal or merely a feeder model for assertions. Otherwise readers may assume both layers are equally mature.
+
+### Medium: revocation and supersession deserve a cleaner conceptual split
+
+The draft treats revocation as withdrawal or supersession, but those are not always the same. One invalidates a prior assertion; the other replaces it with a newer one. This distinction should be sharper.
+
+## Open questions
+
+- Is the first implementable milestone portable assertions only, with trust events described as optional supporting input?
+- Should revocation be kept as a general umbrella term or split explicitly into revoke and supersede actions?
+
+## Residual risk
+
+The document has good boundaries. The main architectural risk is not scope creep but insufficient commitment to a concrete portable core.

workspace/draft-team/cycles/dynamic-trust-and-reputation/50-reviews-v1/ietf-senior.md

@@ -0,0 +1,28 @@
+# IETF Senior Review
+
+## Findings
+
+### High: the draft is credible, but it still reads more like an architecture note than a standards-ready specification
+
+The structure is sound and the layering is disciplined. What it still lacks is the slight extra formality that makes an Internet-Draft feel publishable: clearer field requirements, fewer conceptual transitions, and less reliance on explanatory prose in Sections 5 through 8.
+
+### Medium: the abstract should emphasize scoped issuer opinion sooner
+
+That point is present later in the document and is central to avoiding misuse. It should appear earlier and more explicitly in the abstract.
+
+### Medium: IANA and references remain intentionally provisional
+
+That is acceptable at this stage, but before circulation beyond an internal drafting loop, the document should either define a tiny initial model registry or clearly state that all model identifiers are profile-specific pending later work.
+
+### Medium: terminology is good, but a few terms could be made more standards-native
+
+Portable Trust Assertion and Local Trust State are useful distinctions, though they currently read slightly informal. Tightening those definitions would improve the document.
+
+## Open questions
+
+- Is the intended status Experimental explicitly stated in the draft text anywhere, or only in the cycle metadata?
+- Should the document explicitly note that it does not define trust aggregation across issuers?
+
+## Residual publishability risk
+
+This is a strong first version. The remaining work is mainly to replace architectural vagueness with just enough protocol discipline to withstand IETF-style scrutiny.

workspace/draft-team/cycles/dynamic-trust-and-reputation/50-reviews-v1/security.md

@@ -0,0 +1,28 @@
+# Security Review
+
+## Findings
+
+### High: assertion authenticity is assumed but not tied to required receiver behavior
+
+The draft correctly says portable trust assertions need authenticated origin and integrity protection, but it does not make rejection behavior explicit. A receiver should not be allowed to consume an unauthenticated portable assertion and still claim conformance.
+
+### High: replay handling depends on freshness, but the minimum stale-data rule is too soft
+
+Freshness is mandatory, which is good, but receivers only SHOULD reject or downgrade stale assertions. For clearly expired assertions, that is too weak. A stronger interoperability floor is warranted.
+
+### Medium: negative trust sharing creates reputational poisoning risk without minimum evidence discipline
+
+The document warns about poisoning and privacy, yet evidence references remain entirely optional. That is reasonable for all assertions, but negative portable assertions may need a stronger requirement for explanation or evidence linkage.
+
+### Medium: collusion risk is identified but not operationalized
+
+The draft notes that multiple issuers may not be independent, but it gives no guidance on how a relying party should avoid double-counting related issuers. Even a brief cautionary requirement or implementation note would help.
+
+## Open questions
+
+- Should unauthenticated portable trust assertions be explicitly non-conformant?
+- Should negative assertions require either evidence reference or explanation code?
+
+## Residual risk
+
+Even with improvements, dynamic trust will remain vulnerable to social and operational abuse that pure wire semantics cannot prevent. The draft should state those limits plainly.

workspace/draft-team/cycles/dynamic-trust-and-reputation/50-reviews-v1/software.md

@@ -0,0 +1,28 @@
+# Software Review
+
+## Findings
+
+### High: trust statement models are allowed to vary, but model identification is still too abstract
+
+The draft says a trust assertion must identify its model clearly enough for interpretation, but it never sketches the minimum structure of that identifier. Implementers need at least an abstract field or named model token.
+
+### Medium: receiver processing lacks concrete examples of multi-issuer conflict
+
+The text is directionally correct that aggregation is local policy, but a non-normative example of conflicting assertions with different confidence and freshness would make implementation much easier.
+
+### Medium: trust-event categories are illustrative only, which is safe, but leaves event producers with little interoperability anchor
+
+The draft should either define a small initial event vocabulary or state more clearly that event categories are profile-specific and not intended to interoperate by name in v1.
+
+### Medium: freshness requirements need a clearer shape
+
+The text requires creation time and either expiry or validity policy, but two implementations could still encode validity very differently. The document would benefit from one abstract freshness shape or example.
+
+## Open questions
+
+- Should the document standardize a tiny base model such as `level`, `numeric`, and `delta`?
+- Should it include a compact example trust assertion object?
+
+## Residual risk
+
+The draft is conceptually coherent, but still needs one more layer of data-shape clarity before implementation teams are likely to converge cleanly.