rfi_threads

This table stores the chronological conversation and response events for an RFI. Each row represents one message, response, status note, or official reply within the RFI lifecycle.

Domain: Workflow Engine / RFIs

Scope: Tenant / Project / RFI

Status: Proposed

Last Updated: 11 Apr 2026

Mutable: Append-mostly

Primary Owner: RFI Service / Core API

RLS Applies: Yes

Client Facing: Yes

Purpose

The purpose of this table is to preserve the threaded conversation and formal response history associated with an RFI.

What this table does

Stores threaded discussion and response events for an RFI
Preserves workflow history over time
Supports official responses, comments, and updates
Provides the source for detailed RFI view timelines

Why this table is defined

The RFI record itself should remain compact and query-friendly. The detailed interaction history belongs in a child table so the system can preserve a full discussion trail without bloating the main RFI table.

Columns

Column	Type	Required	Description	Example
`id`	uuid	Yes	Primary key for the thread entry	`rfit_001`
`tenant_id`	uuid	Yes	Tenant owning the thread entry	`tenant_001`
`project_id`	uuid	Yes	Project context	`project_phoenix`
`rfi_id`	uuid	Yes	Parent RFI	`rfi_001`
`entry_type`	text	Yes	Type of entry	`response`
`body`	text	Yes	Text content of the entry	`Architect confirms landing elevation...`
`created_by`	uuid	No	User creating the entry	`user_222`
`external_actor_name`	text	No	Optional external display name	`Laura Chen`
`is_official_response`	boolean	Yes	Marks official response entries	`true`
`parent_thread_id`	uuid	No	Optional reply-to relationship	`rfit_000`
`metadata`	jsonb	Yes	Flexible thread metadata	`{"status_change":"in_review"}`
`created_at`	timestamptz	Yes	Creation timestamp	`2026-04-11 12:00:00+00`

Relationships

rfi_id → rfis.id
parent_thread_id self-references another thread entry
Attachments may be linked through file_links at the application level

How it is used

Rendered as the detailed conversation/history view of an RFI
Used when external guests or project users respond to RFIs
Supports status event logging and official response highlighting

Access and security

Thread visibility must inherit from the parent RFI
Official response creation may need stricter permission checks
Entries should generally be append-only for auditability

Example scenarios

Scenario 1: Architect response

An architect replies to an RFI and the response is stored as a new thread entry.

Scenario 2: Status transition note

When the RFI moves to in_review, a system-generated thread entry records the change.

Scenario 3: Official response

The GC marks one response as the official answer for downstream visibility.

Notes and assumptions

Use entry_type values consistently across the workflow
Consider indexing (rfi_id, created_at) for timeline rendering
Keep the main RFI table separate from discussion/event history