graph TB;
W[Web API] --> D[Data prep]
--> B["Signal Detection</br>(bitstomach)"]
B --> CT
CT["Acceptable Candidate</br>Message Generation</br>(candidate smasher,</br>think pudding)"]
--> E["Message Selection</br>(esteemer)"]
E --> R["Message Rendering</br>(pictoralist)"]

subgraph pipeline
direction TB
W
D
B
CT
E
R
end

The current precision feedback pipeline:

1. Consumes a block of performance data—12 months, cases (as counts), and comparators (as rates) for multiple measures. Some data and business rules are applied.
2. Identifies performance features (trends, gaps, achievements, etc.). This is the bitstomach stage, using signal detectors.
3. Creates potential candidate messages by matching template characteristics to performance features using causal pathways. The generation of candidates (formerly candidate smasher) and identification of acceptable candidates (formerly think pudding) are handled as a single operation.
4. The list of acceptable candidates is scored using a multifactor scoring algorithm (including, performance feature properties, history, and individual and institutional preferences). Once scored a single "best" message is selected.
5. The selected message is rendered graphically and/or as text and returned for downstream processing.

The application currently uses a hybrid, overlapping data model. Most information is represented in an underlying graph. This includes the base configuration—causal pathways, templates, measures, comparators, and working data—as well as performance features, candidate messages, scores, etc. However, many of the concepts used by the app also have a Python class representation, usually created from the underlying graph model, which simplifies the code to manage them.

At this time, the frontend for the app is an HTTP web API accepting JSON requests and producing JSON responses.

The base graph is loaded and instantiated from a list of artifacts found at local or remote locations specified via environment variables. Some additional configuration artifacts are also loaded at startup.

The app uses the rdflib library for graph operations, pandas for data manipulation, and FastAPI for the web API.

graph TB;

    subgraph Web[Web API]
        W["performance</br>info (json)"]
        P2
        R["rendered</br>message (json)"]
    end
    
    subgraph ETL
        DI["performance</br>record(s)"]
        P1 
        DO["message</br>record(s)"]
    end

P1["process"] --uses--> pipeline 
P2["process"] --uses--> pipeline

    subgraph detect["extract perf. features"]
        direction TB
        D[Data prep]
        --> B[Signal Detection]
    end

    subgraph produce[produce message]
    direction TB
    CT[Acceptable Message</br>Candidate Generation]
    --> E[Message Selection]
    end 

    subgraph pipeline
        load["Base graph and config"]  
        detect --> produce
    end

does not reference Scaffold-specific entities such as Candidate, SignalDetector, or any ranking algorithm