Consent & Authority
Evidence is not enough. Authority must be valid. Consent must be honored.
A system can be accurate and still be unauthorized. A model can be useful and still violate consent. OpenIRB places consent and authority inside the review path.
A fail-closed gate: a request passes consent and authority checks before review, or is denied or escalated.
Consent posture asks what permission actually applies.
- What data, subjects, participants, users, or populations are involved?
- What consent was obtained, and what scope does it cover?
- Was consent informed, voluntary, and comprehensible?
- Can consent be revoked? Does secondary use exceed the original consent?
- Are vulnerable populations involved? What privacy duties apply?
Authority posture asks who may act and within what scope.
- Who is the accountable principal? Who owns the system?
- Who may deploy, update, suspend, or revoke it?
- What authority has been delegated to humans, teams, vendors, models, or agents?
- Are agent permissions scoped, expiring, and revocable?
- What happens when authority changes? Can the chain be audited?
Revocation
Revocation must be first-class.
If consent or authority can be granted, it must be possible to revoke, expire, suspend, narrow, or remediate. OpenIRB reviews should record revocation pathways before deployment, not after harm occurs.
Where institutions need cryptographic evidence of delegated authority, consent posture, policy state, action, and decision receipts, OpenIRB can integrate conceptually with EXOCHAIN or compatible chain-of-custody infrastructure. OpenIRB does not imply all reviews require a blockchain. The question is simpler: what must be proven later, and to whom?