Managing the Workspace

This page covers the administrative tasks for managing your Brown Practicum workspace in PrivateLanguage.

Creating a Team Account

1. Sign in to PrivateLanguage at pvtlng.dev
2. From your dashboard, click Create Team in the sidebar
3. Name the team (e.g., "Brown Practicum")
4. You'll be assigned as the Owner with full administrative access

The team account is the organizational container for all course-related data. Every knowledge atom, project, and member lives under this team.

Creating a Project

Within your team account:

1. Navigate to your team workspace
2. Click New Project
3. Name the project (e.g., "Visual Thinking Seminar")
4. Add a description if desired

The project groups knowledge atoms from related sessions. You might use a single project for the entire course, or create separate projects for distinct modules.

Finding Your UUIDs

The ingestion pipeline requires two UUIDs: project-id and account-id.

Finding the Account ID

1. Navigate to your team settings
2. The account ID appears in the URL: pvtlng.dev/home/{account-slug}/settings
3. Alternatively, check the team settings page where the account UUID is displayed

Finding the Project ID

1. Navigate to your project within the team workspace
2. The project ID appears in the URL or in the project settings panel
3. It's a standard UUID format: a1b2c3d4-e5f6-7890-abcd-ef1234567890

Keep both UUIDs handy — you'll use them every time you run the ingestion pipeline.

Adding Students to the Team

1. From your team workspace, go to Members in the settings
2. Click Invite Member
3. Enter the student's email address
4. Assign the Member role (they can view and interact with knowledge but cannot modify team settings)
5. The student will receive an email invitation to join

Students need a PrivateLanguage account. If they don't have one, the invitation email will guide them through sign-up.

Recommended Roles

Reviewing Ingested Knowledge Atoms

After running the pipeline, verify the results:

1. Navigate to your project in the team workspace
2. Browse the newly created knowledge atoms
3. Check that:
   • Idea count is reasonable for the session length
   • Action types are distributed sensibly (not all "proposal")
   • Speaker labels are anonymized correctly (Instructor, Speaker 1, Speaker 2, etc.)
   • Scope tags are meaningful and consistent
   • Relationships connect related ideas logically

The Markdown log produced by the pipeline (in your --output-dir) is useful for a side-by-side comparison with the original transcript.

Monitoring Feedback Submissions

Students can submit feedback from any page using the floating feedback button. To review submissions:

1. Navigate to the Admin panel (accessible to team owners)
2. Go to the Feedback section
3. Review submissions by category:
   • Bugs (red) — prioritize these; something is broken
   • Questions (blue) — these include a student's email for follow-up
   • Knowledge Gaps (cyan) — consider addressing in a future session or updating documentation
   • Hypotheses (purple) — interesting observations to discuss with the class
   • Features (amber) — product improvement ideas to forward to the platform team
   • Feedback (green) — general observations

Acting on Feedback

• Bugs: Report to the PrivateLanguage team or fix if it's a content issue
• Questions: Respond directly to the student's email
• Knowledge Gaps: Use these to identify areas where documentation or captured knowledge needs improvement
• Hypotheses: Consider sharing interesting patterns with the class — they can spark discussion

Best Practices

1. Run ingestion promptly — process transcripts within a day or two of the session while context is fresh
2. Always dry-run first — catch formatting issues before they produce incomplete results
3. Review the Markdown log — spot-check a few ideas against the original transcript for accuracy
4. Encourage student feedback — let students know the feedback tool exists and that you read every submission
5. Check scope tag consistency — over time, ensure the same topics get the same tags across sessions (e.g., always visual-thinking, not sometimes visual-thought)