Document Types

Opheleon uses four document types to move from business intent to implementation detail.

BRD: Business Requirements Document

The BRD explains why the work matters.

It usually includes:

The BRD should not define product flows or technical implementation.

Answers: “Why are we doing this, and what business outcome matters?”

We need workspace-level permissions so growing teams can control access without relying on engineering support for every role change.

Do not include: API contracts, database schemas, or component-level implementation details.

The PRD defines what the product should do.

It usually includes:

The PRD should not make architecture decisions.

Answers: “What should users be able to do, and how should the product behave?”

Workspace admins can invite members, assign roles, change access, and see a clear confirmation before permissions take effect.

Do not include: service boundaries, migration plans, or low-level API behavior.

The HLD explains how the system should be structured.

It usually includes:

The HLD should avoid detailed implementation instructions.

Answers: “What system structure enables the product behavior?”

Permissions are evaluated through a centralized authorization layer used by project, document, and account settings workflows.

Do not include: function-by-function logic, exact schema migrations, or task lists.

The LLD specifies what needs to be implemented.

It usually includes:

The LLD is the layer closest to execution.

Answers: “What exactly needs to change so engineering can implement it?”

Add role checks to project update endpoints, create a role assignment table, migrate existing admins, and add tests for unauthorized edits.

Do not include: broad business rationale or unresolved product decisions that should be settled earlier.