1. What the platform is

Student Profile Studio is the DSDT career platform, the single governed system that serves students, staff, and employers. The sign in screen introduces it in exactly those terms, because the platform is no longer only a résumé builder for students under staff supervision; it is also the place where vetted employers register, are approved by DSDT staff, and then recruit from the students who have been reviewed and published. Everything a student produces still runs through one governed workflow that begins with a first draft and ends with a published, shareable career page, and every consequential action along the way is written to a permanent record.

The platform is best understood as several capabilities working as one. Students build a résumé using either a step by step Guided Builder that offers direction or an Advanced Editor that adds generative AI tools and full control. Whatever they enter is stored as structured profile data and can be rendered through any of a library of professional templates, so changing the design never loses the content. Before anything becomes public, a staff member or administrator reviews the résumé for accuracy, professionalism, and policy compliance, and only an approved résumé can be published. Once published, the student receives a premium public landing page and interactive résumé at a private link built to help an employer evaluate them quickly. Rather than exposing a downloadable file to the open web, the platform routes recruiters through a request and approval step. Every approved and published student is also gathered into one central, searchable Talent Directory.

Layered on top of the student lifecycle is the Employer Recruiting Center, described in full from section 28 onward. Approved employers can discover published candidates, view and download approved résumés under access logging, save and shortlist people, message students on platform, request and schedule interviews, post jobs that DSDT staff must approve before they publish, run recruiting pipelines, and see analytics about their own activity. Administrators govern all of this from the dashboard, principally through an employer approval queue and a job-posting review queue.

A single principle runs through everything. The platform never invents information about a student. Everything a student reports about themselves is kept clearly separate from what DSDT has actually reviewed and published, the AI tools are explicitly forbidden from fabricating experience, credentials, references, or achievements, and the candidate matching shown to employers uses only job related signals and is explainable rather than a black box. That separation, and the human approval behind it, is what makes a published profile credible to an employer.

2. Signing in and multi-factor authentication

Everyone begins at the workspace sign in screen. Sessions are held in a secure cookie and expire after a period of inactivity, at which point the user is asked to sign in again; signing out ends the session immediately. Because the sign in method can be handled through the institution's single sign on where that is enabled, some students and staff authenticate through their school account rather than a separate password. Employers, who are external, register and sign in with a work email and a password of their own, as described in section 30.

Administrator accounts carry a stricter requirement. Any account with the Administrator or Super Admin role must protect it with multi-factor authentication using an authenticator app that generates time based one time passcodes. The first time such an account signs in, the app walks the user through enrollment and then displays a set of one time recovery codes to store somewhere safe. From that point on, every sign in asks for the current six digit code from the authenticator, and if the authenticator is ever lost, each recovery code can be used once to regain access. An administrator's credentials alone are therefore never enough to reach the dashboard; a second factor is always required.

Two further protections sit underneath every session. If an account has been deactivated by a Super Admin, sign in is refused and any sessions it already had are revoked, so removing access takes effect at once. And every action that changes data, not just sign in, must carry a matching security token that the application supplies automatically, so a stolen session cookie on its own cannot be used to make changes. The real-time notification socket described in section 38 authenticates with this same session cookie and refuses any connection that does not resolve to a live, non revoked session.

3. Roles and permissions

There are four internal roles, student, staff, administrator, and super admin, plus the external employer role, which itself carries one of six per organization subroles. Permissions are enforced on the server for every action. This matters: the interface only ever reflects what a role is allowed to do, and hiding a button is never what keeps an action safe, because the server checks the role again on every request regardless of what the browser showed. The table below summarizes the internal roles and the external employer; the six employer subroles are detailed in section 29.

The first governing rule is separation of duties. A student can never approve or publish a résumé that has not already been approved, and a reviewer is never the student who owns the work. This keeps a human other than the candidate accountable for everything that becomes public, which is the foundation of the profile's credibility. The same spirit applies to employers: an employer cannot approve its own organization or publish its own job, because a DSDT administrator sits in between.

The second rule is how the interface adapts to the role. The left sidebar is divided into labeled groups. Everyone signed in as a student or staff member sees a Student Tools group containing the builders, the template gallery, Job Match, and the Talent Directory. Administrators additionally see an Administration group with the dashboard sections; that entire group, including its heading, is hidden from students and staff, so a non administrator never even sees that the administrative tools exist. Employers sign in to a separate employer workspace rather than the student studio.

4. Résumé lifecycle and statuses

Every résumé moves through a governed lifecycle, and each move from one status to the next is written to the audit log with the person who performed it and the time. Knowing the statuses and what unlocks each transition is the single most useful piece of knowledge for supporting students, because most support questions reduce to which status a profile is in.

The rule that decides whether a student is visible is a combination, not any single status. A student appears on their public link, in the directory, and to approved employers only when the résumé is Approved, it has been Published, the owner account is Active, and the publication has not been withdrawn. If even one of those is false, the profile is not shown, and employer candidate and résumé endpoints return a not found response rather than exposing anything. Administrators can make this gate stricter by requiring an explicit approval step before publishing, requiring a stored consent record, or requiring a minimum completeness percentage, all described in section 26.

Edits after publishing are handled carefully. A low risk change such as replacing the profile photo is pushed to the already published page automatically so the live profile stays current without a second review. A larger change to the actual content follows the review path again, so that a human signs off before the changed content reaches the public and before any employer sees it.

5. Studio Home and navigation

Studio Home is the first screen after sign in, and it changes with the role. For a student it is a personal starting point with quick actions to begin building, optimize an existing résumé, and preview the public profile. For an administrator the same screen becomes a command center: it summarizes the health of the platform through a row of metric cards such as the total number of profiles, how many are awaiting review, how many are approved and published, the number of staff and administrator accounts, and the average approval turnaround, and it shows a live activity feed and the current approval queue so an administrator can see at a glance what needs attention.

The left sidebar is the primary means of navigation and is deliberately grouped. Studio Home sits at the top on its own. Below it, the Student Tools group holds the Guided Builder, the Advanced Editor, the Resume Gallery, Job Match, and the Talent Directory. Below that, and only for administrators, the Administration group holds the dashboard sections, which are Overview and Analytics, Students, Staff and Roles, Approvals, Published Profiles, Employers, Communications, Audit Logs, Security, System Settings, Integrations, Help and Support, and the Super Admin dashboard. Note that Analytics is no longer a separate destination: it has been merged into the Overview page, so the side panel link and the top bar Admin Dashboard link both open the same combined Overview and Analytics page. Along the top of every screen runs a bar with a global search box, a notifications bell, and the signed in user's menu, and the sidebar itself can be collapsed to icons when more room is wanted.

6. The Guided Builder

The Guided Builder is the default way a student builds a résumé, and it is designed to remove the intimidation of a blank page. Rather than presenting every field at once, it walks through the résumé one topic at a time, keeps a live preview beside the form so the student can watch the résumé take shape, and shows a completeness meter that reflects how much of the résumé has been filled in. The meter is transparent: it represents the share of the builder's steps the student has satisfied, not an opaque number, so a student always understands what would raise it.

The flow moves through six stops. The Contact step collects the name, work email, phone, and location, and includes a dedicated block for social and portfolio links where the student can add a portfolio or personal website along with profiles such as LinkedIn and GitHub; these links flow onto both the résumé's contact area and the public profile. The Education step captures one or more entries, each with a school, location, degree or certificate, field of study, and a graduation date that may be an expected date, and entries can be freely added or removed. The Experience step is written to reassure a student who worries they have no formal job history: it explains that internships, volunteering, tutoring, babysitting, and similar experiences all count, offers a row of one click chips that seed those common student experiences, and lets each entry record a title, employer or organization, location, dates, a flag for a role the student is still in, and a description. The Skills step lets a student add from a set of expert recommended skills with a single click or type their own, prevents duplicates, and allows any skill to be removed. The Summary step offers pre written professional summary examples that can be dropped into the editor and then personalized. The final Additional Sections step lets the student choose optional sections such as Languages, Certifications, and Volunteer work to include.

Everything entered in the Guided Builder writes to exactly the same underlying profile data that the Advanced Editor, the template gallery, and the public profile all read from. Because there is one shared source of truth, a student can move between the two builders at any time without losing or duplicating anything.

7. The Advanced Editor

The Advanced Editor is the fuller workspace, intended both for students who want complete control and for staff who are helping a student directly. Its layout is a three part workbench: a section navigator on the left that lists the résumé's parts, an editing panel in the center where the current part is edited, and an assistant panel on the right that holds the AI and import tools. The center panel is organized into four tabs. Basic Information captures identity, program, completion year, the professional headline, availability, contact visibility, and the profile photo. Summary and Objective holds the raw verified inputs the student provides and the professional summary itself, with quick actions that can draft a summary, shorten it, expand it, make it more professional, or tailor it toward a target role. Skills and Keywords manages the skill list and the portfolio link and provides a direct entry point into Job Match. Media and Publishing handles uploaded evidence such as images and short video, a review checklist, and the publishing controls.

The assistant panel on the right is where the Advanced Editor earns its name. It hosts résumé import, the AI Studio described in the next section, and the version history. Résumé import lets a student upload a PDF or Word file, or simply paste résumé text, and have the details extracted into the profile for the student to review and correct; because this sends a document to be processed, it requires the student to check a consent box first, and every use is recorded. A prominent AI Studio button in the toolbar scrolls straight down to the AI tools so they are never buried.

The contact visibility control in Basic Information deserves particular attention for administrators. It governs how a student's contact details appear on their public profile page, not what an approved employer sees. By DSDT policy, an approved employer who accesses a published candidate always sees that student's email and phone on the candidate detail panel, regardless of this setting; the setting determines whether those details are shown on, or withheld from, the student's public landing page. Make sure students understand this distinction so they are not surprised that an approved partner can reach them directly. The Publishing Controls card in the Media and Publishing tab explains that the share link is a premium landing page rather than a raw résumé file, and once the profile is published this card shows the exact public URL, which is the identical link an administrator sees for that student under Published Profiles.

8. The AI Studio

The AI Studio is the set of generative writing tools inside the Advanced Editor, and its defining constraint is that it works only from the student's own verified inputs. Each tool produces a small set of candidate suggestions, and each suggestion carries actions to insert it into the résumé, copy it, or regenerate a fresh set, so the student is always the one deciding what to keep.

There are five tools, each aimed at a common weakness in student résumés. Summary options produces two or three tailored professional summary drafts the student can choose between and edit. Headline ideas offers several short, role relevant headline options. Achievement bullets takes a plainly worded duty and rewrites it as an achievement oriented bullet point, without inventing numbers or outcomes that the student did not provide. Keyword and ATS boost suggests keyword and phrasing alignment for the target role so the résumé reads well to the applicant tracking systems many employers use to filter candidates. Claims and ethics check reads the résumé for inflated or vague wording and unsupported claims and flags them for the student to correct, which is the tool that keeps a résumé honest.

Behind the scenes, each tool is fed the inputs most relevant to its job rather than the entire profile; bullet rewriting, for example, works from the student's duties rather than from the already polished summary, so the output stays on point. A profile owner can run these tools on their own profile, and staff and administrators can run them on any profile they are permitted to access. Every run is recorded, and no tool ever marks any information as verified. How the underlying AI provider is configured, and the ethical rules it must obey, are covered in section 37.

9. Templates and design

The Resume Gallery is where a student chooses how their résumé looks. It offers a library of professional templates designed to remain readable to applicant tracking systems, and choosing one never changes the content: the same profile data is simply re rendered in the new layout, so a student can try many designs without any risk of losing what they wrote. Inside the gallery a student can filter the templates, preview any of them live against their own data, and fine tune the design by adjusting the accent color, the font pairing, the spacing, and whether a photo appears on templates that support one. The selected template is remembered and becomes the design used both for the downloadable résumé and for the interactive résumé that a recruiter receives after an approved request, so the student's design choice carries all the way through to the employer.

10. Job Match and Keyword Optimizer

Job Match helps a student aim a résumé at a specific opening. The student pastes in a job description, and the tool compares the posting against the student's skills, headline, and summary, then shows which of the posting's key terms are already covered and which are missing, along with a percentage that expresses how much of the posting the résumé currently addresses. It is careful never to invent skills; the missing terms are presented as candidates the student may add only where they are genuinely true.

The Keyword Optimizer serves a related but different purpose and does not need a job posting. It examines the student's own summary, skills, and notes and scores how ready the résumé is for applicant tracking systems, flagging weak wording, missing action verbs, and results that would read more convincingly with a number attached. Where Job Match tunes a résumé toward one specific role, the Keyword Optimizer strengthens the résumé in general. Neither tool should be confused with the employer side candidate matching in section 35, which ranks students against an employer's own published job.

11. Photo, links, and media

A profile photo can be added in two places, from the drop zone in the Advanced Editor's Basic Information tab or from the photo control in the template gallery, and both routes lead to the same result: the image is resized to a clean square and stored with the profile. That photo becomes the avatar in the hero of the public profile page, the photo on the student's card in the Talent Directory, and the image an approved employer sees on a candidate card. If a student changes the photo on a profile that is already published, the public pages update on their own, so there is no need to walk back through the publish step just to swap a headshot. The only profiles that will not show a photo are those published before any photo existed; in that case the student adds a photo, which then syncs, or re publishes once.

Links are captured alongside the contact details. A student can add a portfolio or website link and social profiles, and these appear in the profile's links area subject to the student's own visibility choices, so a student who prefers to keep a channel private can do so.

Beyond the photo, students can attach supporting media such as project screenshots or a short presentation clip. These uploads are protected on the way in: each file is checked against a size limit, verified to be an allowed type, and scanned for malware before it is accepted, and the file itself is transmitted as encoded data inside an ordinary request so that edge firewalls do not mistake it for something to block. Only files that pass every check are stored, and only public, clean media are ever counted toward what an employer sees.

12. Submitting, revising, and publishing

When a student is satisfied with a draft, they submit it for review. Submitting changes the résumé's status to Pending review and places it in the review queue, and from that point the student can watch the status change and will be given feedback if revisions are requested. If a reviewer does ask for changes, the status becomes Revision requested and the student sees the specific feedback, makes the edits, and resubmits; this loop can repeat as many times as necessary until the résumé is right.

Once a reviewer approves the résumé, it can be published. Publishing does three things at once: it captures a snapshot of the résumé and the profile data as approved, it generates the public share link, and it lists the student in the Talent Directory. That same approved snapshot is what every employer facing surface reads from, so an employer never sees a student's live draft, only the reviewed and published version. Publishing can be performed by the student who owns the profile, by an assigned reviewer, or by an administrator, and publishing an already published profile simply refreshes the public snapshot with the latest approved content.

13. Private improvement tips

On a student's own profile screen there is a private card titled Strengthen your profile that offers concrete, specific advice based on what the profile is currently missing. Depending on the gaps, it might suggest adding a professional photo, writing a professional summary, listing at least five skills, adding a second experience, adding a measurable result to a recent role, connecting a portfolio or GitHub account, or setting a weekly availability. The purpose of this card is to coach the student toward a stronger, more hireable profile. It is deliberately visible only to the student, and none of these recommendations ever appear on the public, employer facing page, so neither a casual visitor nor an approved employer ever sees a note about what the student has not yet completed.

14. The public profile page

Each published student has a premium public landing page at a private link of the form /students/<token>, where the token is a long random string that is effectively impossible to guess. This makes the page link only: it is reachable by anyone who has the link, but it will not be found by browsing or by a search engine. The page is designed so an employer can understand the candidate in well under a minute, and it deliberately reads like a blend of a modern portfolio site, an executive résumé, and a verified credential profile rather than a school portal.

A crucial behavior is that the page renders only the parts the student's data actually supports. There are no empty sections, no blank cards, and no zero value indicators; a section with no content simply does not appear. Reading down the page, the visitor first meets a sticky action bar and a hero area containing the profile photo or initials, the full name, the professional headline, the program and graduation year, the location, an availability indicator, a one line hireability summary, the primary calls to action, and a badge noting that the profile was reviewed and published by DSDT. Directly beneath comes a Candidate Readiness area that presents clearly labeled component cards, for example that a professional summary is present, that skills are listed, that experience is documented, that education is present, that a portfolio is linked, and that availability has been shared, together with a completeness meter that shows the share of those components the profile satisfies. Further down, the professional summary and a set of key strengths drawn from the real data give a quick sense of the candidate, followed by an experience timeline, an education timeline, and a skills area that labels how the skills are evidenced. A portfolio and links area follows.

Near the end sits a Trust and Verification panel, which is the honest heart of the page. It separates the items that are verified, meaning reviewed and published by DSDT, from the items that are student reported, and it never implies verification where none exists. The page closes with the request form for the full résumé, a contact and recruit area, and a QR code for easy sharing. The page is responsive and works in both light and dark mode, is built for accessibility with a proper heading structure, keyboard navigation, and screen reader labels, and prints cleanly. It also carries Open Graph tags and structured data describing a person and a profile page so a shared link previews richly, while still being marked so search engines do not index it. Above all, the full downloadable résumé with contact details is not present on this page; it is delivered only through the request flow described next.

15. Résumé access requests

Rather than publishing a downloadable file to the open web, the platform uses a request and approval flow so students and staff keep control over who receives the complete résumé. The flow begins on the public profile, where an interested employer fills in a short form with their name, work email, organization, and a brief message describing the opportunity. Submitting the form creates a request in the Pending state; it does not release the résumé. This public request flow exists independently of the Employer Recruiting Center, so an employer who has not registered an account can still ask for a copy this way, while a registered and approved employer has the additional, logged résumé access described in section 33.

That pending request then appears in two places. It shows in the student's Résumé access requests inbox on their own Public Profile screen, and it is visible to administrators, in both cases with the requester's details, their message, and a running count of how many requests are waiting. The student or an administrator reviews the request and either approves or denies it, and both outcomes are recorded in the audit log with who decided and when. A request that has already been decided cannot be reopened and flipped to the other outcome, which keeps the history clean and unambiguous.

The consequences of the decision are straightforward. On approval, the requester receives an email containing a secure link where they can view and download the résumé, rendered in the student's chosen design. While the request is still pending, or if it has been denied, that same download link returns an access denied response, so the résumé is never reachable without an approval. The form itself is defended against abuse: submissions are validated, a hidden field silently discards automated bots, and repeated pending requests from the same email address for the same profile are collapsed into a single entry so the inbox does not fill with duplicates.

16. The Talent Directory

The Talent Directory, reachable at /talent, is the one central, employer facing page that lists every approved and published student. It is connected directly to live records rather than being a curated list, which means approving and publishing a résumé adds the student automatically and unpublishing removes them, with no separate step to maintain the directory. The same eligibility rule powers the Recruiting Center's talent search, so a student who appears here is exactly a student an approved employer can discover.

At the top of the page a masthead shows the live count of approved candidates alongside an introduction written for recruiters. Below it, a control bar that stays in place while scrolling lets a visitor search by name, headline, skill, program, or location, filter by program and by availability, sort by most recently approved, by name, or by graduation date, and switch between a grid and a list view. These controls refine the cards already on the page instantly, and they are built as an enhancement rather than a requirement, so even with scripting disabled every card is still shown. Each candidate card presents the photo or initials, the name, the headline, the program, the graduation year, the location, the availability, the top skills, an approved résumé badge, and buttons that open that student's individual profile. The directory shows only profiles that are approved, published, and owned by an active account; drafts, rejected, unpublished, archived, and profiles whose owner has been deactivated never appear.

17. The administrator dashboard

The administration dashboard is reached from the Administration group in the sidebar, or from the Super Admin entry, and it is organized into sections that each load their own panel in place. Those sections are Overview and Analytics, Students, Staff and Roles, Approvals, Published Profiles, Employers, Communications, Audit Logs, Security, System Settings, Integrations, and Help and Support, and the sections that follow in this manual describe each one in turn.

The single most important navigation change to note is that Analytics is no longer a separate page. It has been merged into Overview, which now appears as one combined Overview and Analytics destination. Both the side panel Overview link and the top bar Admin Dashboard link open this same combined page. In practice this means the metric cards, the activity feed, and the approval queue that used to define Overview now sit alongside the platform metrics, completion trends, lifecycle stage counts, and review pipeline throughput that used to define Analytics, so an administrator reviews the health of the platform in one place rather than switching between two. For Super Admins, a Quick Actions area provides one click shortcuts to the tasks performed most often, such as inviting a staff member, opening the approval queue, and running common utilities.

18. Student management

The Students section is the operational view of the student body. It lists the student profile records in the platform and lets an administrator search and filter them, open any profile to review its details and current status, and act on it. In practice this is where an administrator answers questions such as who has a profile, what stage each profile is at in the lifecycle, and which staff member owns or is reviewing a given profile, and it is the starting point for following up on a student whose résumé is stuck or overdue. Because a student's discoverability by employers depends on the same published and active conditions, this section is also where an administrator confirms why a particular student is or is not appearing to recruiters.

19. Staff and role management

The Staff and Roles section, which also appears as the Admin User Table, is where a Super Admin manages every account on the platform. The table lists each user with their name, email, role, account status, sign in method, and the number of profiles they own, and each row carries the controls to manage that account. Understanding what each control does, and the guardrails around it, matters because these actions are consequential.

Inviting a staff member creates a new account by email and assigns it a starting role; the account exists immediately and can then sign in through the institution's method. Changing a role promotes or reassigns a user, and the system refuses to remove the last remaining Super Admin so the platform can never be locked out of its own administration. Deactivating an account is the safe way to remove someone's access: it revokes that account's sessions and blocks any further sign in at once, while preserving every record the account is connected to, and it can be reversed at any time by reactivating.

Permanent deletion is treated as a last resort and is deliberately restricted. It is offered only for accounts that have no profiles and no activity records, so a compliance trail is never destroyed by removing a person. An account with any footprint cannot be deleted at all; its Delete control is disabled and points the administrator to Deactivate instead. An administrator cannot deactivate or delete their own account, and the last active Super Admin cannot be deleted. When a deletion does proceed, any audit entries the deleted account had authored are anonymized rather than erased, so the historical record stays intact even though the person is gone. Every one of these actions is restricted to Super Admins, protected against cross site request forgery, and written to the audit log.

20. Approvals and review

The Approvals section is the review workflow that stands between a student's draft and the public. Submitted résumés collect in a review queue, where a reviewer opens each one, checks it, and records a decision, and reviewers can be assigned to particular profiles so the work is distributed and it is always clear who is responsible for a given review.

When reviewing, the reviewer is confirming that the résumé is complete, professional, accurate, well formatted, and compliant with policy. A pre review assistant can surface likely issues to make this faster, but it is only an aid; it never approves anything on its own, and a human always makes the actual decision. The reviewer then chooses one of three outcomes. Approving clears the résumé for publication. Requesting revisions returns the résumé to the student together with specific, actionable feedback about what to change. Rejecting declines the résumé outright. Whether approval and publication happen as a single combined action or as two separate steps is a configuration choice made in System Settings. Because of separation of duties, the reviewer is never the student who owns the résumé, and every approval, rejection, revision request, and publication is written to the audit log. This student résumé review is distinct from the two employer facing review queues, the employer approval queue and the job-posting review queue, which live in the Employers section and are covered in sections 31 and 32.

21. Published profiles

The Published Profiles section governs the live public pages. It lists the students currently published together with each student's public share link and a way to copy that URL, so an administrator can confirm the correct address for any student and hand it to an employer with confidence. This section is also where an administrator oversees what is visible to the public and unpublishes a profile that should no longer be live. Unpublishing takes the student off both their public link and the Talent Directory while keeping the record, and it also removes the student from employer discovery, because the eligibility rule requires an active published publication. Nothing is lost and the action is fully accounted for in the audit trail.

22. The Employers section

The Employers section is the administrator's control room for the entire Employer Recruiting Center, and it has grown well beyond a place to prepare partner relationships. It now opens with a Recruiting Center platform-analytics strip that summarizes employer activity across the whole platform, and it holds two moderation queues: an employer account approval queue and a job-posting review queue. Everything an administrator needs to govern employers lives here, and the detailed mechanics are described across sections 28 through 36.

The platform-analytics strip is drawn entirely from live records and is intended for DSDT oversight rather than for any single employer. It reports the total number of real employer organizations, how many are approved or active, how many are pending review, how many are suspended, the number of active recruiter memberships, how many jobs are currently published and how many are in review, the total résumé views and downloads across all employers, the total employer messages, the total interviews and how many are scheduled, the total job invitations, and the number of applications, along with a breakdown of organizations by verification status. These are counts over real activity, so they are an honest measure of how the Recruiting Center is being used.

The employer account approval queue is where an administrator works through organizations that have registered and verified their work email and are waiting for a decision. From here an administrator can approve or activate an organization, request more information, reject it, suspend an active one, reactivate a suspended one, deactivate an account, or attach an internal note, each of which is explained in section 31. The job-posting review queue, explained in section 32, is where an administrator approves, rejects, or requests revisions on jobs that employers have submitted, since no job reaches students until DSDT has approved it. Both queues are gated to administrators and super admins, every decision is protected against cross site request forgery, and every decision is written to the audit log.

23. Communications

The Communications section is where messaging across the platform is organized, including student notices, the templates used for revision messages, staff announcements, and employer outreach, so what the platform says to students, staff, and employers stays consistent and intentional. It should not be confused with the on platform employer to student messaging described in section 34, which is a direct, thread based channel between an approved employer and an individual student; Communications is the administrator's own outbound and template tooling, while employer messaging is a recruiting feature that keeps a student's email private and stays entirely on platform.

24. Audit logs

The Audit Logs section is the searchable record of sensitive activity across the entire platform, and it is the first place to look whenever an administrator needs to reconstruct what happened and who did it. Every meaningful action is written here, including sign in events, profile submissions, approvals, rejections, revision requests, publications and unpublications, role changes, account deactivations and deletions, and résumé request decisions. The Recruiting Center adds its own entries to the same trail: every employer moderation decision, every job review decision, every résumé view and download an employer performs, and the creation of hiring-team tasks are all recorded. Each entry captures the actor who performed the action, or records that there was no signed in actor in the case of an anonymous public action such as an employer submitting a résumé request, along with the action itself, the target it acted on, the time, and, where policy permits, the network address of the request. Because deleting a user anonymizes rather than erases the entries that account authored, the trail remains complete even as accounts are created and removed.

25. Security console

The Security section gives a Super Admin a view of the platform's protective posture. It surfaces active sessions, the multi-factor authentication status of accounts so an administrator can confirm every privileged account is protected, the password and lockout policy, and the data protection controls. In day to day use it is where a Super Admin verifies that administrators have their authenticator enrolled, reviews who has access, and keeps an eye on the controls that keep student data safe. The concrete protections this section reflects are described in full in section 40.

26. System settings and governance

System Settings is where an administrator configures how the platform behaves, and its most consequential controls are the publishing governance rules that decide when a student may go public. There are three governance controls, and together they set how strict the publish gate from section 4 will be. Requiring approval before publishing means a résumé must reach the Approved status before it can be published, which is the core protection that keeps unreviewed content off the public web and away from employers, and it is the setting most institutions will keep on. Requiring a consent record means publishing is only permitted when there is a stored record that the student consented to being made public, which is useful where written consent is a policy or legal expectation. Requiring profile completeness means a résumé must reach a minimum completeness percentage, which the administrator sets, before it can be published, so half finished profiles cannot go live.

These three settings also determine whether approval and publication are treated as one action or as two separate steps in the workflow. A parallel governance idea applies on the employer side: DSDT requires administrator approval of every employer organization before it can touch private student data, and administrator approval of every job before it can publish, so the same principle of a human gate before exposure holds for recruiters as for students. Beyond governance, this section is where broader configuration lives, covering branding, workflow behavior, notification preferences, privacy defaults, data exports, and maintenance mode.

27. Integrations

The Integrations section manages the external services the platform connects to. The two long standing ones are the email provider, which is Mailjet and is covered in section 38, and the AI provider, which is covered in section 37, and this area is also where single sign on, storage, and other workspace connections are configured. The Recruiting Center adds one more optional integration, native Google Calendar sync, which pushes a scheduled interview to the organizer's connected calendar. That integration is inert until DSDT configures Google OAuth credentials, and it is described in section 39. A point that matters for security across all of these is that the credentials for external services are held in the server environment rather than in the browser; they are never sent to the client application and are never visible to students or employers, so connecting a service does not expose its secret.

28. The Employer Recruiting Center at a glance

The Employer Recruiting Center lets vetted employers register, get verified and approved by DSDT staff, and then discover published student candidates, view approved résumés, and organize prospects, all under authorization and privacy rules that are enforced on the server. From an administrator's point of view the Recruiting Center is something to govern rather than operate: employers do the recruiting, and DSDT decides which employers are allowed in and which jobs may reach students. This section and those that follow describe the whole feature set so an administrator understands exactly what is being permitted.

The shape of the flow is simple to hold in mind. An employer creates an account with a work email, verifies that email, and waits for a DSDT administrator to review and approve the organization. Until that approval, the organization can see the shell of the product but cannot reach any private student data, cannot message, cannot download résumés, and cannot schedule interviews. Once approved, members of the organization, each limited by their subrole, can search the talent directory of eligible candidates, open candidate profiles, view and download approved résumés with every access logged, build shortlists, message students on platform, request and schedule interviews, post jobs for DSDT approval, run pipelines and candidate matching, invite candidates to apply, and see analytics about their own activity. The eligibility rule for which students an employer can see is identical to the public directory: a student must have an active published publication, be in the published state, and have an active owner account.

The Recruiting Center is feature complete against its original specification. Alongside the core recruiting features, three capabilities that were once optional are now built and are covered later in this manual: real-time push of notifications over a WebSocket, saved-search alerts, and native Google Calendar OAuth sync. The calendar integration is real but remains inert until DSDT sets its Google credentials, so nothing about it is assumed to be active by default.

29. Employer roles and capabilities

Employer authorization has two layers. The first is the global user role. Every employer user carries the global role employer on the users table, which distinguishes them from students, staff, and administrators, and any endpoint reserved for employers rejects a user whose global role is not employer. The second layer is the per organization subrole. Within an organization, each membership carries exactly one of six subroles, and a given user has at most one membership per organization.

The six subroles are owner, administrator, recruiter, hiring manager, interviewer, and viewer, and what each can do is decided by a fixed capability matrix rather than by ad hoc checks. There are five capabilities. The manage_org capability, held by owner and administrator, covers editing the organization profile and, in the design, future billing, integrations, and ownership transfer. The manage_team capability, also held by owner and administrator, covers inviting members and changing their roles or status. The recruit capability, held by owner, administrator, and recruiter, is the workhorse: it covers saving and managing candidates, creating and editing candidate lists, starting and replying to message threads, creating, rescheduling, and canceling interviews, and drafting, editing, and running the lifecycle of jobs, inviting candidates, and adding, moving, and removing pipeline records. The review_candidates capability, held by owner, administrator, recruiter, and hiring manager, is required, in addition to being an assigned interview participant, to submit interview feedback. The view capability is held by every subrole and is the baseline for read access.

Enforcement is entirely on the server, and the frontend never decides access. When a request arrives, the platform resolves the signed in user's active membership and organization, then, for anything beyond a bare read, additionally requires that the organization be approved or active and not suspended, and finally, for a capability guarded action, rejects the request unless the member's subrole is in that capability's allowed set. An administrator supporting an employer should therefore reason in terms of both layers: an interviewer who cannot start a message thread is not experiencing a bug, but the capability matrix working as designed, and an owner of an organization still awaiting approval is blocked not by their subrole but by the organization's verification status.

30. Registration and work-email verification

Employers onboard themselves. Registration creates three things at once: a user with the global role employer and a hashed password, an organization with a unique slug and the submitted company details starting at the status email verification required, and a membership linking that user to the organization as its owner. Registration is refused unless the employer agrees to the terms and acknowledges the data policy, and the timestamp of that data use agreement is recorded. A duplicate email is refused as a conflict. On success the new owner is signed in immediately so they can see the verify or pending shell, and a verification email is sent, though a failure to send the email does not block the registration itself.

The verification email carries a signed token. When the owner follows it, the platform validates the token, confirms it matches the organization's contact email, and, only if the organization is still at email verification required, advances it to pending review, at which point it enters the administrator approval queue. An owner who did not receive the email can request that it be resent while the organization is still unverified. Administrators should understand that this email step verifies control of the address, not the legitimacy of the employer; the legitimacy judgment is the administrator's, made in the approval queue.

Free or consumer email providers such as Gmail, Outlook, Yahoo, iCloud, and Proton are allowed rather than blocked, but a registration from a public email domain is flagged for extra scrutiny: the organization's notes are seeded with a message recommending extra verification, and the registration response marks it as a public email registration. This gives the reviewing administrator a clear signal to look harder at an organization that did not register from its own corporate domain, without preventing a legitimate small employer from getting started.

31. Verification lifecycle and the approval queue

An employer organization moves through a defined set of verification statuses, and an administrator working the approval queue is moving organizations between these statuses. Only an organization whose status is approved or active may use employer features and reach private student data; every other status blocks that access. The table below lists the statuses and what each means.

The approval queue itself lists real employer organizations, which the platform recognizes by their non empty slug so that legacy invite only employer contacts are not mixed in, and it can be filtered by status, showing owner information, member counts, and a running count of how many organizations are pending review. From an organization's record an administrator applies a moderation action with an optional note. Approving sets the organization to approved and records who verified it and when; activating does the same and sets it to active; both grant access and email the owner. Requesting information moves the organization to additional info required and emails the owner with the note. Rejecting moves it to rejected and emails the owner. Suspending moves an active organization to suspended, records the suspension reason, and emails the owner. Reactivating returns a suspended organization to active. Deactivating turns the account off. A note action changes no status but appends a dated, attributed note to the organization's record. An unknown action is refused, and every action is written to the audit log.

The practical governance point for an administrator is the boundary this queue enforces. An organization that is anything other than approved or active is walled off from private student data: it cannot open candidate details, cannot view or download résumés, cannot message students, and cannot schedule interviews, and the relevant endpoints simply reject the attempt. Approval is therefore the deliberate act that opens the door, and suspension or deactivation is the act that closes it again, both fully logged and both notifying the employer.

32. The job-posting review queue

Jobs that employers post do not reach students until a DSDT administrator has approved them. Because approval is required, an employer's job travels through a lifecycle of draft, then submitted into the review queue, then an administrator decision, and only then can the employer publish it. The job-posting review queue in the Employers section is where that administrator decision is made. It lists jobs awaiting review, defaulting to those that have been submitted, together with a count of how many are pending.

For each submitted job an administrator records one of three decisions with an optional note. Approving moves the job to approved and records who approved it and when, which is what makes the job eligible for the employer to publish. Rejecting moves the job to rejected. Requesting revisions moves the job to revisions requested and returns it to the employer to amend, with the administrator's note stored on the job's review notes so the employer sees exactly what to change. An unknown decision is refused, and every decision is written to the audit log.

It is worth being precise about the boundary between the administrator's role and the employer's. The administrator approves or declines; the administrator does not publish. Once a job is approved, the employer performs the actual publish step, at which point the job becomes visible to students in their opportunities feed according to its visibility setting. This keeps the same separation of duties that governs student résumés: a human at DSDT authorizes exposure, but the party who owns the content carries out the final publish. An administrator who wants to stop a job that is already live works through the employer relationship and the audit trail rather than editing the employer's posting directly.

33. Discovery, résumés, and saved candidates

Once an organization is approved, its recruiting members can discover talent. Talent search runs over exactly the eligible candidate set, meaning students with an active published publication, in the published state, owned by an active account, and it offers filters for a free text query, program, availability, location, and skill, along with sorting by most recent, name, or program, and pagination. Search result cards are deliberately lean: they carry the same public facing summary a directory card shows and never include contact details. Opening a candidate's full detail is a separate, logged action.

Candidate detail and the résumé itself are built from the approved published snapshot, not from the student's live draft, which is why an employer only ever sees the DSDT reviewed version and why the candidate detail can honestly mark the profile as school reviewed. A résumé is served only when the approved snapshot actually contains résumé content; otherwise the request is refused. Regarding contact details, DSDT policy is that an approved employer may see a candidate's full contact information on candidates it is permitted to access when the student has chosen to show those details, and the candidate detail includes email and phone precisely in that case; when the student has kept contact details hidden, the employer sees the candidate without them. Independently of what a candidate card shows, employer to student messaging always keeps the student's email address private and on platform, so an employer can reach a student through the platform even when it cannot see an email address.

Every résumé relevant action an employer takes is logged. Opening a candidate detail records a view, and fetching the résumé records a view, or a download when the employer explicitly downloads it. These access logs capture the organization, the profile, and the acting user, they feed the résumé view and download counts an employer sees in its own analytics and the totals an administrator sees in the platform strip, and each one also writes to the general audit log, so an administrator can always reconstruct which employer looked at or downloaded which student's résumé and when. Beyond discovery, recruiting members can save candidates, optionally into reusable candidate lists that act as shortlists or talent pools with either team or private visibility, attach private notes, and manage all of this per organization. Saving is idempotent, so saving the same candidate twice for one organization does not create a duplicate. All of an organization's saved candidates, lists, logs, and searches are scoped to that organization, so one employer never sees or affects another employer's data.

34. Messaging and interview scheduling

On platform messaging lets an approved employer and a student converse without ever exchanging email addresses. A thread is scoped to exactly one organization and one student; any active member of the organization participates on the employer side, and the student is the sole participant on the candidate side. Starting a thread requires the recruit capability and an eligible candidate, and if a thread between that organization and that student already exists it is reused rather than duplicated. Replying on the employer side also requires the recruit capability, while simply reading threads requires only that the organization be approved. A student can always list, read, and reply to their own threads but cannot start one. Every message triggers an in app notification to the counterpart, no email address is ever disclosed, and message bodies are capped in length. Each message also carries a moderation status, and a message a moderator has removed is shown as removed text rather than its original body, which gives DSDT a lever over abusive content while keeping the rest of the conversation intact.

Interview scheduling lets an employer propose times, a student respond, and interviewers record private feedback. Creating an interview requires the recruit capability, an eligible candidate, and at least one valid proposed time, and it starts awaiting the student's response with the organizer added as an auto accepted participant and any named interviewers from the same organization added as well. The student then accepts a specific proposed time, which schedules the interview and sets its start and end, declines, or requests a reschedule; responding to an interview that has already been canceled or completed is refused. An employer can propose new times, which returns the interview to awaiting the student, or cancel with a reason. Once an interview is scheduled with a confirmed time, both parties can download a standard calendar invite file, and if native calendar sync has been configured the organizer's connected Google Calendar also receives the event as described in section 39.

Interview feedback is private to the employer team. Submitting feedback requires the review_candidates capability and that the acting user is actually a participant on that interview, and each interviewer's scorecard, recommendation, and private notes are upserted so there is one feedback record per interviewer. The student's own view of an interview never includes internal instructions or any interviewer feedback, so scorecards stay within the hiring team. As with messaging, every employer read and write is scoped to the organization and every student read and write is scoped to that student, so no party ever sees another conversation or another candidate's interview.

35. Jobs, matching, invitations, and pipeline

Jobs are the backbone of active recruiting. A recruiting member drafts a job, which starts in draft and can be edited freely until it reaches a terminal state, then submits it for the DSDT review described in section 32. After an administrator approves it, the employer publishes it, and a published job carries a visibility of public or directory, both of which surface it to students in their opportunities feed, or invite only, which keeps it out of the feed and reachable only through a direct invitation. A job records the usual details, including title, department, description, responsibilities, qualifications, a capped list of skills, an employment type, a work arrangement, location, a compensation range and period, and the number of openings, and it can later be paused, closed, marked filled, or archived. There is also an AI assisted drafting helper that returns suggested description, responsibilities, qualifications, and skills from a title and optional notes; it only ever returns draft text for the employer to edit, it is instructed not to invent company facts, compensation, or protected trait requirements, it falls back to a deterministic offline draft built only from the supplied title and notes when no AI provider is configured, and it never creates or publishes a job on its own.

Candidate matching ranks eligible candidates against a published job and is explainable by design rather than a black box. For each candidate it surfaces the job's required skills the candidate has, the required skills the candidate lacks, human readable reasons such as how many required skills are present and whether the program aligns with the role, and a transparent score derived only from those surfaced factors. It also flags candidates already in the job's pipeline. The matcher uses only job related signals, skills, program relevance, and stated availability, and it never reads or weights protected characteristics or proxies for them, which is the same honesty principle that governs the rest of the platform.

Invitations and the pipeline complete the loop. An employer can invite eligible students to apply to a published job, subject to a per call cap and with no duplicate invitations, and each new invitee receives an in app notification with no email exposure. A student sees invitations and open opportunities in their opportunities feed and either applies or declines. Each job also has a configurable pipeline of ordered stages, and a recruiting member can add an eligible candidate at a chosen stage, move a candidate between stages with an optional reason, or remove a candidate. When a student applies, their profile is automatically entered into that job's pipeline at the applied stage and the job owner is notified. All of this is scoped to the organization, so one employer's jobs, invitations, and pipelines are invisible to every other employer.

36. Employer analytics and hiring-team tasks

Every approved organization can see analytics about its own recruiting, computed entirely from its live records with nothing fabricated or projected, and scoped strictly to that organization. The headline metrics count active, draft, and in review jobs, saved candidates, résumé views and downloads, messages sent, invitations sent, applications, interviews requested and completed, hires, and open hiring-team tasks. Alongside these are three breakdowns that make a funnel visible: jobs grouped by status, pipeline records grouped by stage, and interviews grouped by status. There is no per student behavioral tracking beyond the résumé access logs the employer itself generated, which is an important point to be able to state plainly to a student who asks what an employer can see about them.

The administrator equivalent is the platform-analytics strip in the Employers section, described in section 22, which aggregates the same kinds of counts across every real employer so DSDT can watch how the Recruiting Center as a whole is being used. Where an employer's analytics answer how is my own hiring going, the administrator's strip answers how is the whole program going.

Hiring-team tasks are lightweight shared to dos for an employer's team, optionally linked to a job or a candidate. A member can create a task with a title, an optional description, a priority, an optional due date, and optional links, list the team's tasks, update a task including marking it done, which stamps a completion time, and delete a task. If a task is assigned to a specific person, that person must belong to the organization; otherwise it defaults to the creator. Task creation is written to the audit log, and every task read and write is scoped to the organization, so one team's tasks are never visible to another.

37. AI provider and ethics

All of the platform's AI features run on the server, never in the student's browser, and they are directed by a single configured provider route that can take one of three values. It can point to an external provider, currently xAI's Grok. It can use a local policy engine that runs entirely on the server and makes no external calls. Or it can be disabled. The important practical detail is that when an external provider is not configured, or when a call to it fails, the platform automatically falls back to the local policy engine, which produces useful, task aware output for the very same tools. Because of that fallback, the AI Studio, the pre review assistant, and the employer job drafting helper all keep working whether or not an external provider is connected, and an outage never blocks a user.

When an external provider is used, student text is protected before it ever leaves the server: identifying details are redacted and the request is minimized to only what the task needs, and the exact content that was sent is recorded so there is a clear account of it. The ethical rules the AI must follow are strict and are not optional. The AI must never fabricate experience, invent certifications, create fake references, mark credentials as verified, approve a résumé without a human, make discriminatory recommendations, or infer protected characteristics. This governs the employer facing AI as well: the job drafting helper is instructed not to invent company facts, compensation, or protected trait requirements, and the candidate matcher is built to use only job related signals and to explain itself rather than emit a black box percentage. Every suggestion the AI produces is presented as a suggestion for a person to accept or edit, and final approval, in every case, requires an authorized human being.

38. Notifications, email, and real-time delivery

Users are kept informed inside the workspace through in app notifications. For students and staff these cover review and publication events; for the Recruiting Center they cover new messages, interview proposals and responses, job invitations, applications, and saved-search matches. Every notification is written as a durable in app record and delivered to the recipient, and none of them ever disclose an email address, so a student can be notified that an employer has messaged them without the employer learning the student's email, and the reverse holds too.

On top of the durable notifications sits an optional real-time delivery path over a WebSocket. A connected client receives a notification the instant it is created, but this is an enhancement rather than a requirement: the real-time event is only actually pushed after the request that created the notification has committed, which avoids a client refetching before the record is written, and if a client has no live socket it simply falls back to the existing polling and loses nothing but immediacy. The socket authenticates with the same signed session cookie as the rest of the platform and closes any connection whose session is missing, revoked, or expired. One deployment caveat is worth recording for administrators: the real-time registry is in process, so in a multi worker deployment a push only reaches clients connected to the same worker, and a future multi worker setup would route pushes through a shared channel; the durable notifications and polling are unaffected either way.

Outbound email is handled separately and is delivered through the Mailjet sending service. Its uses today are to notify an employer when a résumé request is approved with a secure link to view and download the résumé, and to send the Recruiting Center's transactional messages such as work email verification, team invitations, and the owner notifications that accompany approval, information requests, rejection, and suspension decisions. Email is configured entirely on the server using a Mailjet API key and secret, a validated from address, a display name, and the public base URL used to build absolute links, and this configuration is deliberately kept out of the browser. If email has not been configured, the platform simply skips sending and carries on; email is best effort and never blocks a request or a decision. When an expected email does not arrive, check that the Mailjet key and secret are set without stray characters, that the sender address has been validated in Mailjet, and the recipient's spam folder.

39. Saved-search alerts and calendar sync

Two Recruiting Center conveniences deserve their own explanation because their behavior is easy to misread. The first is saved-search alerts. A recruiting member can save a set of talent-search filters under a name, keeping only the recognized filter keys, and choose an alert frequency of off, instant, or daily. Running a saved search executes those filters over the very same eligible candidate set the interactive directory uses, and it compares the current matches against the set of candidates seen at the previous run to work out which matches are genuinely new. The first run establishes a baseline and never alerts, which prevents an employer being notified about the entire existing directory the moment they save a search. On later runs, when there are new matches and the alert frequency is not off, the search owner is notified of the new candidates. It is important to understand that there is no background scheduler today: alerts fire only when a search is actually run, and the stored frequency of instant or daily currently only gates whether a run emits an alert rather than driving any automatic execution.

The second convenience is native Google Calendar sync, which pushes a scheduled interview to the organizer's connected Google Calendar. This is a real OAuth integration, not a mock, but it is inert until DSDT configures Google OAuth credentials, namely a client id, a client secret, and a redirect URI from a Google Cloud OAuth client with the Calendar API enabled, none of which live in the codebase. Until those are set, the calendar status reports that it is not configured, the connect endpoint returns a service unavailable response, and interview event push is skipped, while the standard calendar invite download continues to work as the always available path. When it is configured, an employer connects a calendar through the usual consent flow, the access and refresh tokens are stored encrypted rather than in plaintext, and an expired access token is refreshed transparently. When a student accepts a proposed time and the interview becomes scheduled, the platform makes a best effort attempt to create the event on the organizer's own primary calendar; the push never raises an error into the interview flow and only ever touches the organizer's calendar, never the student's, since the student continues to rely on the invite file download.

40. Security, privacy, and compliance

The platform is built defensively, and its protections are worth stating plainly. Access is governed by role based access control enforced on the server for every sensitive action, which means the interface can never be used to slip past a permission, because the server checks the role again on every request regardless of what the browser showed. For employers this is doubled up: the server checks the global employer role, then that the organization is approved and not suspended, then that the member's subrole carries the needed capability. Every request that changes data must carry a matching security token, defeating cross site request forgery, and administrators are additionally required to use multi-factor authentication, so a privileged account cannot be taken over with a stolen password alone.

Activity is recorded comprehensively. Every sensitive action, including all employer moderation and job review decisions and every employer résumé view and download, is written to the audit log, and because deletion anonymizes rather than erases, the record survives even as accounts change. Uploaded files are handled with suspicion by design: each is validated by type and size and scanned for malware before it is accepted, and imports are transmitted as encoded data so edge firewalls do not block them. Stored secrets are protected as well: external service credentials live only in the server environment, and calendar OAuth tokens are encrypted at rest. The public pages are hardened, running under a strict content security policy that forbids third party scripts, marked so search engines do not index them, using unguessable link tokens, and never displaying a full street address.

Privacy is placed in the student's hands and reinforced by the employer boundary. A student controls whether their contact details are shown, and that choice flows through to what an approved employer can see. The full résumé is always gated, whether behind an approved public request or behind an approved employer's logged access to an eligible, published candidate. Employer messaging keeps a student's email private and on platform, interview feedback is never shown to the student, and an employer that is not approved, or has been suspended, can reach no private student data at all. Consent for publication can be required and is recorded. Taken together, these controls mean a student's information is only ever as public as the student and DSDT have agreed, and every consequential action, by a student, a staff member, an administrator, or an employer, can be traced to a specific party at a specific time.

41. How the data connects

A brief mental model of how the records relate makes troubleshooting much easier. A user account has a role and, for students, owns one or more student profiles. A student profile holds the résumé content and its lifecycle status and is linked to its owner and, when one is assigned, to a reviewer. When a profile is published, the platform creates a publication record that stores a snapshot of the résumé and the public data along with the public token used in the share link; the public profile page, the Talent Directory, and every employer facing candidate view all read from these publication snapshots, which is why the public and employer views reflect the approved state at the moment of publishing, plus automatic updates such as a changed photo. A résumé request record ties an external requester to a profile, carries its own pending, approved, or denied status, holds a private token, and is what the approval email links to.

The employer side layers its own records on top. An employer organization has a verification status and, through memberships, a set of employer users each with a subrole. Around an organization sit its saved candidates and candidate lists, its résumé access logs, its message threads and messages, its interviews with their participants and private feedback, its jobs with their pipeline records and invitations, its hiring-team tasks, its saved searches, and, per user, an optional encrypted calendar connection. Every one of these employer records is scoped to its organization, and the ones that reach into student data, saved candidates, résumé logs, threads, interviews, pipelines, and invitations, always resolve the student through the same eligibility rule, so an employer record can only ever point at a student who is genuinely published and active.

The practical takeaway is two sentences that explain most visibility questions. A student is publicly visible, and discoverable by employers, precisely when a published, active publication exists for an approved profile owned by an active account, and removing any one of those conditions removes the student everywhere at once. An employer can act on private student data precisely when its organization is approved or active and the acting member's subrole carries the needed capability, and losing either of those closes the door.

42. URL and route reference

The platform exposes a small number of stable public addresses, summarized below. These are all link only and are not indexed by search engines, and their tokens are long and random so a profile or request cannot be discovered by guessing. The employer and administrator features described in this manual are reached through the signed in application and its employer and admin APIs rather than through public links, so they are not listed here as shareable addresses.

43. Troubleshooting and FAQ

A student is not showing in the Talent Directory or to employers. Confirm the résumé is both Approved and Published and that the owner account is Active. Draft, rejected, unpublished, and archived profiles never appear, and neither does a profile whose owner has been deactivated. The same combination governs employer discovery, so this one rule explains almost every missing student.

The public link shows the landing page but there is no downloadable résumé. This is by design. The landing page promotes the student, while the full résumé with contact details is delivered only after a résumé request has been approved, or to an approved employer through its logged access.

A profile photo is not appearing on the public page or a candidate card. Have the student upload or re upload the photo; on a profile that is already published the public and employer views then update on their own. A profile published before any photo existed may need a single re publish to pick it up.

An employer cannot open candidates, message, download résumés, or schedule interviews. Check the organization's verification status. Only an organization that is approved or active has access; one that is still pending review, awaiting more information, suspended, rejected, or deactivated is walled off from all private student data by design. If the organization is approved, check the member's subrole against the capability matrix in section 29.

An employer's job is not visible to students. A job reaches students only after a DSDT administrator approves it in the job-posting review queue and the employer then publishes it. Confirm the job is not still in draft, submitted, revisions requested, or rejected, and that its visibility is public or directory rather than invite only.

An employer says they cannot see a candidate's email or phone. That is the student's choice. Contact details reach an approved employer only when the student has set their profile to show them; otherwise the employer sees the candidate without them and can still reach the student through on platform messaging, which never exposes the email.

Approval or verification emails are not arriving. Check the Mailjet key and secret for stray characters, confirm the sender address is validated in Mailjet, and look in the recipient's spam folder. If email is not configured at all, the underlying actions still succeed correctly; only the notification email is skipped.

Calendar sync is not working for an employer. Native Google Calendar sync is inert until DSDT sets the Google OAuth credentials. Until then the calendar status reports it is not configured and the standard calendar invite download is the working path; confirm the credentials are set before treating a missing calendar event as a fault.

An account should be removed but the Delete control is disabled. The account has profiles or activity records, so it can only be Deactivated, which fully blocks access, in order to preserve the compliance trail. Permanent deletion is reserved for accounts with no footprint.

44. Glossary