Private Mentor/Reviewer Context Sharing

Why “send the whole learner profile” is a dangerous shortcut

A mentor needs the latest assessment and two project artifacts to review a debugging plan. The current system sends the entire learner profile for convenience: private notes, unrelated career data, and anything that might be useful. That hides three failures at once: the sharing purpose is vague, field minimization is not provable, and revocation may not invalidate already-issued context packages.

This lesson builds Purpose-Bound Mentor Context Share Grant & Provenance Envelope v1. Every share binds purpose, authorized mentor/reviewer, authorization or basis, requested and approved scope, a minimum-necessary reason per field, redaction, an immutable source snapshot, issue/expiry/revocation times, onward-sharing policy, and access/audit events. Mentor annotations remain separate from source facts and never silently rewrite the canonical learner record.

The goal is not to maximize context. It is to create a bounded, auditable sharing contract that preserves HOLD, REVOKED, REVIEW_REQUIRED, or INSUFFICIENT_EVIDENCE when proof is missing.

For: learning-platform engineers, mentor/reviewer workflow designers, privacy/security reviewers, and QA. Not for: legal conclusions, use of live learner data without authorization, or mutation of canonical production records.

Route and lesson boundary

Foundation learners use the field map and baseline. Repair learners isolate the first broken evidence dimension. Experienced learners defend the trade-off among convenience, least privilege, auditability, and revocation without collapsing it into a synthetic score.

MKN-028 owns private mentor/reviewer context sharing only. MKN-027 is a soft prerequisite around authoring/editor context; MKN-029 owns mentor quality and escalation next. This lesson does not invent legal basis, derive local policy from NIST, or issue real access.

Three checkpoints drive the route: F1 restates scope; F2 rejects one shortcut using an exact field/state; F3 independently recomputes two grants after one optional purpose is revoked.

Mental model: a context share is a temporary projection, not a profile copy

The core flow is:

review purpose → reviewer authorization → minimum-necessary field selection → redaction → immutable source snapshot → time-bound context grant → access log + separate annotations → expiry/revocation

The canonical learner record stays unchanged. A context package is a projection from a fixed snapshot for a specific purpose and has its own lifecycle. Changing purpose does not silently expand scope. Revocation must invalidate derived packages or cached access. Annotations retain provenance to the reviewer and source snapshot but remain derived notes, not source facts.

Keep authority classes separate: FACT (what an external source says), INFERENCE (why bounded projection and logging are reasonable), and DESIGN (MAKNOW field classes, expiry windows, role matrix, and revocation behavior).

Foundational contract: identity, scope, provenance, and state

Decision-critical fields include context_share_id, learner_ref, purpose, mentor_or_reviewer_ref, role, authorization_ref, consent_or_basis_ref, requested_scope, approved_scope, field_id, field_class, minimum_necessary_reason, redaction_rule, source_record_ref, source_snapshot_hash, snapshot_created_at, annotation_ref, annotation_author, grant_state, issued_at, expires_at, revoked_at, onward_share_state, download_state, access_event_id, and audit_event_id.

Four invariants matter. First, every field is purpose-bound; trust in a person is not purpose-specific authorization. Second, every package is snapshot-bound. Third, annotations are separated from source facts. Fourth, time and revocation are first-class: expiry cannot be extended after issuance without a governed authorization/revision, and revocation must affect derived packages.

Preserve typed non-success states: UNKNOWN, UNVERIFIED, STALE, REVOKED, REVIEW_REQUIRED, HOLD, and INSUFFICIENT_EVIDENCE.

Designing the grant, redaction map, snapshot, and audit trail

Purpose and authorization. Express the task as a testable purpose, such as “review debugging plan for assessment A-91,” then bind a reviewer role and authorization reference. Grading authority does not automatically authorize coaching or career review.

Minimum necessary. Requested scope is an input; approved scope is the result of a gate. Each approved field carries a reason. A career profile that is irrelevant to debugging review is excluded even for a trusted reviewer.

Redaction. Record what was removed or masked and why. Provenance can still point to the source snapshot hash without disclosing the removed private field.

Snapshot isolation. Build the package from a fixed snapshot. The canonical record may evolve later, but the reviewer must be able to prove which version was exposed. Annotations reference the snapshot rather than rewriting the source.

Expiry and revocation. Treat grant and package lifecycle separately from canonical history. Extending expiry is a governed revision, not a field edit. Revocation constrains tokens, package state, cache eligibility, and emits an audit event.

Onward sharing. Default to DENIED. A new recipient or scope requires explicit authority; team membership is not enough.

Audit. Log issuance, access, and revocation with identity, action, actor, package/grant reference, time, and outcome without duplicating private content in the log.

Worked baseline: bounded debugging-review context

The baseline uses learner L-204, reviewer REV-42, and purpose DEBUGGING_PLAN_REVIEW. The reviewer requests a recent assessment, two project artifacts, a private mentor note, and a career profile. Authorization AUTH-77 covers technical review only. The approval gate removes the unrelated private note and career data, records a minimum-necessary reason for each included field, and records redaction reasons for excluded fields.

Source snapshot SNAP-204-A is immutable and hash-bound. Grant CTX-204-DBG-01 is issued September 13 and expires September 15. Onward sharing is DENIED, an access event is logged, and annotation ANN-77 references the snapshot without modifying the canonical learner record.

The synthetic baseline therefore yields ACTIVE_BOUNDED. This does not claim legal authorization for a real disclosure; it means the fixture satisfies the design contract. MKN-028-T1 and lab://MKN-028/MKN-028-LAB1 make the decision replayable.

Failure modes that must fail closed

1. Add unrelated career fields to an active review grant without changing purpose → HOLD / SCOPE_EXCEEDS_PURPOSE.
2. Extend expires_at after issuance without a new authorization or revision → HOLD.
3. Revoke the grant but leave a cached package accessible → HOLD and invalidate the package.
4. Write a mentor inference into the canonical learner record as a source fact → HOLD.
5. Omit authorization or basis → INSUFFICIENT_EVIDENCE or HOLD.
6. Omit the source snapshot hash → provenance is not replayable.
7. Permit onward sharing because the recipient is a trusted teammate → HOLD without explicit authority.
8. Omit access/audit events → the decision cannot be fully auditable.

Repair the smallest broken dimension; never invent evidence or authority.

Experienced bridge: model context packages as temporary capabilities

At scale, treat a grant like a bounded capability: subject, purpose, scope, source snapshot, temporal bounds, and policy state. The package is merely a materialization of that capability; the exported file does not define permission.

A useful architecture separates a canonical store for source facts, a context package store for purpose-bound projections, and an annotation store for derived reviewer notes. Stable references and provenance join them. Revocation need not erase canonical history; it invalidates the capability/package and closes access paths.

In multi-reviewer workflows, each reviewer has an independent grant. Their scopes do not union just because the learner identity is shared. An active grading authorization cannot cancel a coaching revocation or expand either reviewer's scope.

Alternatives and trade-offs

Full profile + role access: operationally simple, high scope drift and audit ambiguity. Dynamic field projection: stronger least privilege, more field-classification and rule maintenance. Prebuilt review bundles: convenient, but stale and over-broad templates are risky. Short-lived signed packages: clearer expiry/revocation, but download and cache policy still matter. No-download browser view: reduces file leakage, but authorization, screenshot/export, and audit boundaries remain.

No pattern is automatically privacy-compliant. Keep reviewer cost, latency, explainability, revocation propagation, retention, and qualified privacy/legal review visible. If decisive policy evidence is missing, choose the weaker state.

Guided and independent practice

Guided: open the baseline. For each requested field, record its purpose link, field class, minimum-necessary reason, and approve/redact decision. Bind the snapshot, issue/expiry window, onward-sharing state, and access event. Run gate_rules.py without looking up a prefilled final decision.

Repair: inspect unrelated_career_scope.json. Do not simply delete the field; explain why the current purpose cannot support it and what new governed purpose/authorization would be needed.

Independent transfer: one optional coaching purpose is revoked while a separate grading reviewer still has an active task. Recompute grants independently, invalidate only affected packages, preserve audit history, and prove that one authorization does not expand the other.

The starter contains no hidden answer key; visible rules and fixture evidence are the oracle.

Verification: what must the evidence actually prove?

For the baseline, the artifact must expose share/learner/reviewer identity, purpose, authorization/basis, requested and approved scope, per-field minimum reasons and redactions, snapshot hash, annotation separation, issue/expiry/revocation state, onward-sharing state, and access/audit events.

The producer suite contains twelve deterministic tests covering baseline success, unrelated scope expansion, silent expiry extension, revoked cached access, annotation contamination, missing authorization, missing snapshot, unauthorized onward sharing, missing access logging, missing minimum-necessary reason, and two independent transfer cases. Every decisive mutation fails closed.

This verifies the bounded design contract, not real-world legal compliance or production access-control security.

Assessment and changed-context transfer

S1 tests boundary retrieval. S2 requires the complete baseline envelope. S3 diagnoses unrelated scope expansion. S4 recomputes the transfer from changed evidence.

In transfer, the learner revokes OPTIONAL_COACHING while GRADING_REVIEW retains independent authorization. The correct bounded state is MIXED_ACTIVE_REVOKED: the coaching package is revoked and invalidated, the grading package remains active bounded, both histories remain auditable, and no scope union occurs. If the grading reviewer receives an extra career field merely because the coaching reviewer once had it, the transfer must HOLD.

All five rubric dimensions are blocking: identity/contract, evidence binding, negative evidence, bounded decision, and transfer. The baseline label is never the oracle.

References, claim boundaries, and freshness

1. NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk. It does not itself authorize a specific learner-data disclosure. In 2026, NIST continues work on Privacy Framework 1.1 through the update/Initial Public Draft process.
2. NIST SP 800-53 Rev. 5 includes Access Control and Audit and Accountability control families. Those controls are guidance, not legal authority to share learner context.
3. Grant schema, field classes, expiry/revocation behavior, onward-sharing defaults, and annotation separation here are MAKNOW DESIGN.

The official sources were rechecked on 2026-09-13. Practice-evolving claims must be requalified by 2027-01-15 or earlier after a material guidance change. Accepted package bytes are never silently rewritten; canonical changes require a new version.

Closing question: which shortcut creates the most false confidence in your current workflow—full profiles, long expiry, onward sharing, or annotation contamination—and which exact evidence field exposes it?