Purpose

This is a founder-facing ownership dossier for output_allocations.

It does not force a decision.
It records the evidence currently visible in code.

VERIFIED current implementation surface

Persistence implementation:

• services/svc-tenders/src/repository/outputAllocations.ts

Root compatibility / ownership surface:

• services/svc-tenders/src/repository.ts

HTTP route exposure:

• services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts
  • GET /admin/output-allocations
  • GET /admin/output-allocations/:id
  • POST /admin/output-allocations
  • PUT /admin/output-allocations/:id

Current server wiring:

• services/svc-tenders/src/server.ts
  • output-allocation methods are composed into auction declaration route registration

Web client surface:

• apps/web/src/ui/auctions/allocation/client.ts

What the data looks like

The table shape, as seen from code, carries:

• allocation_id
• stakeholder_id
• productive_asset_id
• asset_type
• product name/category
• quantity/unit
• quality/origin/season/storage details
• availability window
• allocation_state
• evidence summary
• creator metadata

This looks more like a registry / inventory allocation record than a narrow auction bid record.

Evidence pointing toward auction ownership

1. Route exposure is currently auction-admin aligned

Evidence:

• services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts

Why it points toward auction:

• current CRUD/admin surface is colocated with auction declaration routes
• declaration flows validate allocationId while building auction announcement drafts

Strength:

• VERIFIED
• moderate evidence

Limit:

• colocated route exposure is not proof of final ownership

2. Current operational usage is auction declaration prep

Evidence:

• findOutputAllocationById(...) is used by auction declaration draft/update/declare path checks in services/svc-tenders/src/routes/registerAuctionDeclarationRoutes.ts

Why it points toward auction:

• current workflow is “prepare an auction around an allocation”

Strength:

• VERIFIED
• moderate evidence

Limit:

• this proves current usage, not final product owner

Evidence pointing toward settlement / financial ownership

1. The concept is closer to pre-auction or pre-sale inventory allocation than announcement content

Evidence:

• fields describe asset/product availability and storage semantics, not just announcement metadata

Why it points toward settlement/financial side:

• allocation records may be upstream of pricing, entitlement, release, or settlement logic

Strength:

• INFERRED

Limit:

• code does not yet prove a strong financial-layer write path

Evidence pointing toward shared registry ownership

1. The data shape looks reusable outside auctions

Evidence:

• the record is about productive asset output availability, quality, season, storage, and evidence summary
• none of those fields are inherently tied to bidding mechanics

Why it points toward shared registry:

• the same allocation object could plausibly support auctions, direct sale, financing, or fulfillment preparation

Strength:

• INFERRED

Limit:

• no separate shared registry service or package exists yet

What the code does NOT currently prove

It does not prove that output_allocations are:

• definitively auction-owned
• definitively financial-layer owned
• definitively shared-backbone owned

Current best verdict

Ownership verdict today:

• VERIFIED: currently hosted with auction declaration admin flow
• INFERRED: conceptually closer to shared registry / pre-settlement allocation capability
• final owner: UNVERIFIED

System state:

• REAL

Recommended founder decision framing

Use this question:

Is output_allocations meant to exist only to feed auction declarations, or is it meant to be a reusable record of allocatable productive output across multiple commercial flows?

If answer is:

• “only auction preparation”

  • future auction ownership is stronger

• “reusable output registry for multiple flows”

  • future shared registry/backbone ownership is stronger

• “it will drive entitlement/release/payment mechanics”

  • settlement/financial ownership becomes stronger

Safe next step

Do not decide only from route colocation.

Safer next step:

• document expected business lifecycle for an output allocation
• list all intended future consumers
• then assign final domain ownership