Luma

Luma is an Elementum-based service request platform. It provides a configurable workflow for submitting, validating, approving (with optional multi-round approval), and executing service requests. Request types are defined as pluggable skills, so new kinds of requests can be added without changing the core flow.

Overview

• Validate — User submits a request; the system runs type-specific validation (preview or submit).
• Approve — Requests are routed to one or more approvers based on type-specific rules; each round can assign the next approver dynamically.
• Execute — When all approvals are done, a type-specific automation runs to fulfill the request.

The core engine is generic; each request type (e.g. pencil order, AD group change) is implemented as a skill with its own validation, approval logic, and execution.

Repository structure

apps/
├── service-request/                    # Core service request app
│   ├── agents/                         # Agents that drive the flow
│   │   ├── intake-agent/               # Intake: skill search, validate, submit
│   │   ├── approval-agent/             # Approval actions
│   │   └── execute-agent/              # Execution trigger
│   ├── automations/                    # Shared automations
│   │   ├── execute.yaml                # Wrapper: calls skill.execute
│   │   ├── set_next_approver.yaml      # Assigns next approver per round
│   │   ├── validate_and_confirm.yaml   # Validation preview (no commit)
│   │   └── validate_and_submit.yaml   # Validation + submit
│   └── DIAGRAMS.md                     # Sequence diagrams for the full flow
│
└── service-request-management/        # Admin / extensibility
    ├── agents/
    │   └── builder-agent/              # Creates new service request types
    └── skills-registry/                # Pluggable request-type skills
        ├── ad-group-service-request/   # AD group add/remove requests
        │   ├── SKILL.md                # Inputs, validation, approval rules
        │   ├── automations/            # validate, set_next_approver, execute
        │   └── DIAGRAMS.md
        └── pencil-service-request/     # Pencil order requests (example)
            ├── SKILL.md
            ├── automations/
            └── DIAGRAMS.md

Apps

service-request

Runs the main lifecycle: validate → approve → execute.

• IntakeAgent — Helps users find skills, run validation preview (ValidateAndConfirm), and submit (ValidateAndSubmit).
• ApprovalAgent — Used when approvers act on requests.
• ExecuteAgent — Invoked when a request is READY_FOR_SERVICE; the generic execute automation delegates to skill.execute implemented by each skill.

Automations:

• validate_and_confirm / validate_and_submit — Call the skill’s skill.validate; submit path also sets status to READY_FOR_APPROVAL.
• set_next_approver — Triggered when status is READY_FOR_APPROVAL; calls the skill’s skill.set_next_approver when needed, assigns the next approver, sends notifications, and either loops for another round or sets status to READY_FOR_SERVICE.
• execute — Sets status to IN_PROGRESS, calls skill.execute, then sets status to COMPLETED or FAILED.

See apps/service-request/DIAGRAMS.md for sequence diagrams.

service-request-management

Provides Builder Agent and a skills registry.

• Builder Agent — For admins to register new service request types (implementation details TBD).
• skills-registry — Each subfolder (e.g. pencil-service-request, ad-group-service-request) is one request type:
  • SKILL.md — Name, description, inputs, validation rules, and approval routing rules.
  • automations/ — validate.yaml, set_next_approver.yaml, execute.yaml for that type.

The generic automations call skill.validate, skill.set_next_approver, and skill.execute; the skill is resolved from the record's request_type (e.g. pencil-service-request).

Adding a new request type

1. Add a new folder under apps/service-request-management/skills-registry/, e.g. my-service-request/.
2. Add SKILL.md with frontmatter (name, description, allowed_tools, etc.) and sections for inputs, validation rules, and approval rules.
3. Implement in automations/:
   • validate.yaml — Validate payload; return success or failure.
   • set_next_approver.yaml — Populate approvers and/or pick the next approver for the current round.
   • execute.yaml — Perform the actual fulfillment; return success or failure.
4. Optionally add DIAGRAMS.md for that type.
5. Register the type with the Builder Agent / app configuration so the core app can resolve the skill and call skill.validate, skill.set_next_approver, and skill.execute for new requests.

Example skills

• pencil-service-request — Order pencils (quantity, type, recipient); validation and approval by role (Office Manager, Department Head, Art Supply Manager).
• ad-group-service-request — Add/remove principals to/from AD groups; high-risk and Admin-group routing to CISO; otherwise IAM team.

See each skill’s SKILL.md and automations/ for the exact contract and behavior.