Concourse & Jira DC Portal

Put Simply Statement:
Need a place to onboard Estimation Models and provide them with: name / describe / version

Why it Matters:
Admins will need a way to onboard Models and provide their high level details

What’s Needed:

• Tied to BOTH the Create model button and to the duplicate option (will likely exist as an edit option)

• Slideout (I think this would be better than a continuous form)
  
  

Early ACs:

• Given an Admin is on the Estimation Model Slideout, when they view the form, then they will see the following fields:

  • Fields in top to bottom order: Model Name, Model Description, Version (do we want to standardize this maybe?), Comments (if needed)

  • They will not see the left hand nav for other config pages if creating or duplicating a model

• Given an Admin is on the Estimation Model Slideout, when they view the bottom of the form, then they will see a create/save button in the bottom right and a back button in the bottom left

  • Save if making edits IF we want to allow edits to name / description / version name

  • Create if creating a duplicate or fresh model

• Given an Admin is on the Estimation Model Slideout, when they click create, then their new Estimation Model we be added to the Estimation Landing page table with the details in the form

• Given an Admin is on the Estimation Model Slideout, when they click create, then they will see a pop up asking them if they want to configure the Estimate details or go back to the Estimation Landing page

  • Sub-text XYZ

• Given an Admin is on the Estimation Model Slideout, when they click view the top of the form, then they will see text Overview and sub-text

BACKEND:

Feature: Estimation Model Onboarding API & Data Handling

Description:
Expose backend APIs and database services to create, duplicate, edit, and retrieve Estimation Models with metadata (name, description, version, comments).

Scope:

• Endpoints:

  • POST /estimation-models → Create new model

  • POST /estimation-models/{id}/duplicate → Duplicate an existing model

  • PUT /estimation-models/{id} → Update model details (name, description, version, comments)

  • GET /estimation-models/{id} → Retrieve a single model (for edit view)

  • GET /estimation-models → List all models (for landing page table)

• Database Schema:

  • id (UUID / auto-generated)

  • name (string, required, unique per tenant)

  • description (string, optional)

  • version (string, required; enforce standard format if agreed)

  • comments (string, optional)

  • created_at / updated_at (timestamps)

  • created_by (admin user reference)

• Business Logic:

  • Validation for unique model name + version combinations.

  • Optional versioning standardization (semantic versioning rules).

  • On duplicate: clone metadata and mark as new record with new ID and incremented version if needed.

  • Return structured error messages for validation failures (e.g., “Model name already exists”).

• Integration:

  • Ensure newly created/updated models immediately appear in landing page list.

  • Return confirmation metadata for frontend modal (e.g., {id, name, nextActions} payload).

Acceptance Criteria:

• Backend persists new/duplicated/edited models correctly.

• API validations enforce required fields and uniqueness constraints.

• API responses match contract expected by frontend (consistent field names).

• Backend logs all create/update actions for auditing.