Public and Partner Academy Model
The Mandaitor Academy is designed as a public learning layer for the market and an eventual gated partner enablement layer for delivery teams. The public Academy should remain easy to access because it explains the core problem: agentic systems need bounded, verifiable, auditable authority before they act. Partner enablement material, however, must not be published in the public documentation site because it can include delivery methods, workshop scripts, internal positioning, completed client-style examples, and operational playbooks.
Why this split matters
Mandaitor benefits from a public Academy because the category of verifiable delegated authority is still new for many stakeholders. Public education reduces onboarding friction, supports evaluation, and gives founders, builders, reviewers, and implementation leads a shared vocabulary. A consulting partnership creates a second need: partners require repeatable delivery material that should be protected behind access control rather than shipped as public static pages.
| Layer | Primary audience | Suitable content | Access model |
|---|---|---|---|
| Public Academy | Prospects, evaluators, developers, reviewers, and governance stakeholders. | Core concepts, role-based routes, glossary, public capstone framing, evaluator guidance, and high-level pilot readiness. | Public web. |
| Gated Partner Academy | Approved consulting partners, certified advisors, and delivery teams. | Workshop kits, facilitator guides, demo runbooks, client templates, certification tasks, delivery checklists, and completed examples. | Partner-authenticated access. |
| Client project workspace | A specific customer team and approved partner/Mandaitor participants. | Filled-in capstone outputs, pilot charter, evidence-review notes, decisions, risks, owners, and rollout gates. | Tenant, project, or engagement-scoped access. |
| Internal Mandaitor layer | Mandaitor team members only. | Roadmap-sensitive guidance, pricing-sensitive positioning, internal objection handling, and partnership strategy. | Internal-only access. |
What remains public
The current Academy should keep teaching the ideas that make Mandaitor understandable before a user touches the product. Public pages should explain concepts and support self-serve evaluation, but they should avoid revealing partner delivery IP.
| Public Academy area | Purpose | Example output |
|---|---|---|
| Role-based routes | Help each stakeholder choose a learning path. | A founder, builder, reviewer, or implementation lead knows which lessons to read first. |
| Foundations | Explain why capability and access are not the same as delegated authority. | A learner can describe principal, delegate, verifier, mandate, and evidence. |
| Product learning path | Connect Academy ideas to evaluation and adoption. | A team understands how to move from concept to product confidence. |
| Capstone Pilot Workbook | Provide a public, high-level pilot framing exercise. | A team can outline a bounded first workflow and evaluation questions. |
| Getting Started guide | Convert learning outputs into an evaluator run. | A technical evaluator can create a mandate and verify an action. |
What must be gated
Partner enablement material should be held outside the public documentation deployment. It may reuse public terminology and link back to public lessons, but it should be delivered through a private repository, authenticated partner portal, or dashboard-based partner area.
| Gated partner material | Why it should not be public | Recommended home |
|---|---|---|
| Consulting workshop kit | It contains repeatable delivery methods and partner-facing facilitation IP. | Private partner Academy repository or authenticated partner portal. |
| Facilitator notes and agendas | They describe how consultants steer client conversations and manage workshop flow. | Gated partner enablement space. |
| Completed client-style templates | They can reveal strategic positioning, assumptions, or implementation patterns. | Engagement-scoped workspace or partner portal. |
| Demo scripts and objection handling | They may include sales, delivery, or roadmap-sensitive guidance. | Internal or partner-authenticated space depending on sensitivity. |
| Certification rubrics | They define partner qualification and should be controlled. | Partner portal with learner identity and completion tracking. |
| Pilot expansion playbooks | They can include commercial and operational growth motions. | Partner-only enablement area. |
Shared structure without shared exposure
The public and gated Academies should use the same vocabulary, module names, personas, and capstone language. This keeps the learner journey coherent while preserving access boundaries. A public lesson can introduce the concept of a bounded workflow; the gated continuation can tell an approved consultant how to facilitate a client workshop that produces a pilot charter.
| Public page | Gated continuation |
|---|---|
| Role-based learning routes | Partner delivery routes for seller, solution architect, governance advisor, and implementation lead. |
| Capstone Pilot Workbook | Facilitator workbook, completed examples, scoring rubric, and client-ready workshop output template. |
| Getting Started guide | Partner demo runbook, scenario pack, failure-mode guide, and technical objection handling. |
| Governance, Risk, and Compliance | Control-mapping worksheet, client interview guide, and evidence-review checklist. |
| Product Learning Path | Demo choreography, screenshot talking points, and pilot expansion playbook. |
| Development Status | Partner-facing maturity positioning and guidance on what should not be promised yet. |
Implementation rule
Confidential partner content should not be placed into the public Docusaurus bundle, even if it is hidden from navigation. Static-site builds can still expose unpublished routes, source maps, or bundled content if the material is present at build time. The safer pattern is to keep partner content in a separate private source of truth and publish it only behind authentication.
| Option | Use when | Recommendation |
|---|---|---|
| Private partner Academy repository | Mandaitor needs a fast, controlled place for partner materials while the dashboard model matures. | Best near-term option. |
| Authenticated dashboard partner area | Mandaitor wants partner roles, progress tracking, certification, and cohort reporting. | Best long-term option. |
| Public repo with hidden pages | The content is non-sensitive and merely not relevant to most users. | Do not use for consulting workshop kits or delivery IP. |
Governance checklist
Before creating a new Academy asset, decide whether it belongs in the public Academy, the gated partner layer, the client project workspace, or the internal Mandaitor layer. The decision should be based on the audience, confidentiality, commercial sensitivity, and whether the asset could create risk if copied out of context.
| Question | If the answer is yes | Recommended placement |
|---|---|---|
| Does this teach a general concept that helps the market understand Mandaitor? | Publish it openly. | Public Academy. |
| Does this help an approved consultant run a client workshop or pilot? | Gate it. | Partner Academy. |
| Does this contain filled-in client context, stakeholder names, or pilot decisions? | Scope it to the engagement. | Client project workspace. |
| Does this include pricing, roadmap, internal positioning, or sensitive objection handling? | Keep it internal or tightly partner-gated. | Internal Mandaitor layer or restricted partner area. |
Recommended next step
The immediate implementation path is to keep improving the current public Academy while creating a private partner enablement source of truth. The public Academy should link conceptually to the partner model, but it should not expose private workshop kits. Over time, the partner layer can move into an authenticated Mandaitor dashboard area with partner roles, synced learning progress, certification, and cohort reporting.