The safeguarding model, in full.

Contact

• S.01An adult can never initiate contact with a student. Not through messages, not through mentorship, not through any path. Enforced at the query layer and re-checked at send time.
• S.02Open messaging exists only within a peer class: student↔student and adult↔adult. Adult↔student open messaging does not exist on the platform.
• S.03Even staff↔student open messaging is blocked. Contact between staff and a student happens through structured, visible channels such as appointment requests — never private open threads.Fail-closed by design: when we had to choose, we chose the stricter reading.
• S.04Students are never browsable or searchable by alumni or any external adult. An alum who opens a student's profile link gets a full block, not a redacted view.
• S.05A student's contact details and last name never reach an adult. A mentorship request shows an alum the student's first name, interest, and message — nothing more.

Discovery & mentorship

The point of the platform is students reaching the alumni who did the thing they're curious about — safely, with the school or organization in the loop the whole way.

• S.06Students discover alumni through safe professional fields only: name, field, employer, city. Never contact details, never private fields.
• S.07An alum appears in student discovery only after opting in. Alumni control their own availability to students.
• S.08Every mentorship request goes to a counselor or admin for review before the alum ever sees it. Rejected requests return to the student; nothing reaches an adult unreviewed.
• S.09Contact begins only when the alum accepts an approved request — and the conversation that opens is monitored from the first message. The adult still never initiates.

Monitoring & the record

• S.10Every adult–student interaction writes an immutable audit entry: the request, the approval, the acceptance, every message event. The log is append-only; nobody can edit history.
• S.11Message contents are never copied into logs. The audit trail records that contact happened and between whom — the conversation itself stays in the monitored thread, and personal information never lands in log files.
• S.12Adult–student conversations are visible to your own admins. During the early phase, Arcus staff supervise alongside them.
• S.13Automated screening for off-platform-contact attempts, grooming-pattern language, and personal-information sharing is built into the adult–student message path.Honest status: it is not switched on yet. It begins running only once an AI provider is configured under no-training, zero-retention terms, and its alerts are then calibrated with pilot communities before they reach admins. Until that day, the safety net is human review and the audit trail — not an algorithm. We would rather tell you that than let you assume a screen that isn't watching.
• S.14Any member can report any message or post. Reports surface to admins immediately — reporting has no calibration period and is always on.

Peers & consent

• S.15The student peer directory is visible only to students and your own staff and admins. Alumni and external adults never see it — for them it simply does not exist.
• S.16A minor appears in the peer directory only after affirmatively opting in at signup. No recorded consent means not listed, and every consent change is audit-logged.
• S.17Where a school or organization, or its jurisdiction, requires guardian consent, we configure that flow with you during onboarding.

Data & isolation

• S.18Every profile field carries a visibility level — public to the community, connections only, or private — enforced on the server on every read. Private fields are visible only to the owner and your own staff.
• S.19Only the owner can edit a profile. Not other members, not admins. (Arcus support overrides exist for emergencies and every one is audit-logged.)
• S.20Data is encrypted in transit and at rest, and we hold a hard gate on ourselves: no real roster is imported until field-level encryption covers the most sensitive fields, like personal phone numbers and home addresses.
• S.21Each school or organization's data is isolated from every other's. Every query is scoped to a single tenant, with database row-level security as a second, independent enforcement layer beneath the application.
• S.22No personal information in system logs, ever. No card data on our servers, ever — payments run through Stripe's hosted checkout and settle to your school or organization's own account.
• S.23Export and deletion are built in from the start: a member can ask for their data or ask for it to be gone. FERPA-aware posture, with the school or organization as controller.