[
  {
    "file": "getting-started.md",
    "description": "How to set up dotBEP from scratch. Covers account creation, installing Node.js and Claude Desktop, generating a personal API token (dbk_), configuring the MCP connector in claude_desktop_config.json, creating a first BEP through a conversation with the AI, viewing it in the platform, and using the Local/Published toggle for real-time preview while editing."
  },
  {
    "file": "mcp-server.md",
    "description": "How dotBEP's AI authoring model works via the Model Context Protocol (MCP). Covers compatible AI clients (Claude Desktop, GitHub Copilot, Gemini CLI, Cursor, Windsurf), what the connector enables (list, open, read, edit, and save BEPs), the open-source nature of the .bep format and core library, and the live Local preview toggle."
  },
  {
    "file": "working-with-your-bep.md",
    "description": "The session-level operational flow for working with a BEP. Covers how to list and open a BEP, the difference between own BEPs (full edit) and shared BEPs (read-only with query access), the two save types (patch for minor changes, version for milestones), the Local vs Published toggle, how unsaved changes persist locally across sessions, and how to share a BEP by adding participants."
  },
  {
    "file": "authoring-guide.md",
    "description": "The recommended sequence for authoring a complete BEP, with example prompts for each section: BIM objectives, phases and milestones, teams/roles/members, BIM uses, workflows (node types: start/end/process/decision/automation; edge behaviors: events/conditions/effects; RACI assignments), information requirements (LOIN, LOD/LOI per milestone), location breakdown structure (LBS), and deliverables (TIDP/MIDP). Standards and guides have their own dedicated doc. The primary reference for BEP content authoring."
  },
  {
    "file": "standards-and-guides.md",
    "description": "How to define standards (rules, naming conventions, modeling requirements) and guides (curated collections of annexes linked to workflow actions) in a BEP. Covers adding a standard, referencing other BEP data (teams, reference data, disciplines, the naming convention, other entities) directly from a standard's prose via inline {{...}} JSONata references so it always reflects the current state, embedding a live table of that data, why any entity a standard mentions by name (software, teams, other standards) should be referenced inline rather than typed as plain text, why structured data (allowed values, required fields, folder structures) should be defined as reference data instead of prose so workflows and other automations can read it with certainty, adding a guide and its annexes, linking guides to workflow actions, and reviewing what is already defined."
  },
  {
    "file": "ai-memory-and-skills.md",
    "description": "The two persistence mechanisms for AI-assisted authoring across sessions. Memory stores facts and decisions the AI maintains automatically (continuity across sessions, with commands to read, add, or remove entries). Skills store behavioral rules defined once and applied proactively by the AI (writing style, confirmation steps, structuring conventions). Includes guidance on when to use memory vs. a skill."
  },
  {
    "file": "bep-execution.md",
    "description": "How dotBEP turns a BEP into executable software. Covers the execution engine, workflow instances (one per asset or deliverable, with full transition history), tracked assets (internal deliverables or external URLs), the runtime (TypeScript code that implements effects and automations), events (signals that advance instances), effects (automatic actions that fire on transitions, such as notifications), automations (non-human workflow steps), and triggers (how external software initiates workflow instances). Includes how to write the runtime manually, with AI assistance, or with support from the dotBEP team."
  },
  {
    "file": "workflow-design-patterns.md",
    "description": "Prescriptive modeling patterns and best practices for designing dotBEP workflows, beyond what each node and edge type does. Intended both for project teams authoring a BEP and for AI assistants modeling a workflow on their behalf."
  },
  {
    "file": "bep-data-and-execution.md",
    "description": "How BEP data is used operationally by the execution engine at runtime. RACI assignments become enforced access control (the engine validates the user's role before allowing any event emission). Teams and members resolve roles to actual users at runtime (user to member to role to node). Workflow structure defines the only valid deliverable state transitions, with no manual overrides outside the defined flow. The BEP schema is the authoritative source of truth for all runtime behavior."
  },
  {
    "file": "reports.md",
    "description": "How to use reports to communicate the live state of a BEP during project execution. Reports are AI-generated Markdown documents that support visual elements through dotBEP Flavored Markdown (DFM): stat cards, progress bars, pie charts, area charts, timelines, matrices, and callout blocks. Covers workflow instance reports, remote data reports, combined reports, example prompts for each type, and where reports appear in the platform. For the full DFM syntax reference, see the dedicated dotBEP Flavored Markdown doc."
  },
  {
    "file": "dotbep-flavored-markdown.md",
    "description": "Full syntax reference for dotBEP Flavored Markdown (DFM), the set of visual block elements dotBEP adds on top of standard Markdown. Covers the :::token syntax (stat cards, progress bars, pie charts, area charts, timelines, matrices, callout blocks, and the entity table block for referenceData, disciplines, teams, and deliverableNamingConvention), plus the {{...}} inline JSONata reference syntax used in standards' prose. DFM is available anywhere dotBEP renders Markdown: reports and standards."
  },
  {
    "file": "ideas-worth-trying.md",
    "description": "Advanced use cases for AI-assisted BEP authoring: migrating an existing BEP from Word/PDF/Excel, following local BIM guidelines by sharing a URL (e.g. Colombia BIM Kit), extracting BEP content from project documents (contracts, scope documents), using a previous BEP as a template for a new project, creating workflows from diagram screenshots, turning video tutorials into project standards, generating role profiles from workflow RACI assignments, turning meeting transcripts into BEP content, and asking the AI to review the BEP for completeness and gaps."
  },
  {
    "file": "remote-data.md",
    "description": "How to connect external data sources to a BEP and use them for live visualization and AI context. Covers defining remote data sources (ACC, Google Drive, ERPs, custom apps), visualizing them in the platform using built-in lenses or custom lenses built with the runtime template, using them as context for AI queries and reports, and the closed-loop pattern where workflow automations write results back to external systems so remote data reflects the current state of execution."
  },
  {
    "file": "reference-data.md",
    "description": "How to define reference data (informationDomains and referenceData) in a BEP: structured, domain-organized facts such as status enums, CDE folder structures, or required file metadata fields, meant to be read with certainty by external systems or referenced from a standard's prose. Covers the two main use cases (external configuration and standards references), domains and nodes, the difference between key (technical identifier) and label (human-readable name), grouping data of the same shape together, and referencing other BEP data from within reference data."
  }
]