Active Project Specifications
Needs Your Attention
Recent Activity
Flow reference
Project Specification → Materials Spec → Pricing → Offer. v1 = steps 1+2.
Source documents
AI triage summary
Units check 15 per typology · 50 minimum total
| Typology | Units | Rule |
|---|---|---|
| ≥ 15 < 15 · drop? | ||
| Total | ≥ 50 no offer |
Rule is undocumented but sacred (call-notes.md:82–85). EUR 6K design cost per typology = uncompetitive below 15.
Country regulation profile
- ·
Rule tables maintained by Maurizio's ufficio tecnico. System applies; does not research.
All items reviewed
You've decided on all rows. You're ready to move to Pricing.
Confidence per row
Caveat — this mockup: the green / yellow / red chips on each row are hand-authored in the demo data to illustrate the UX. The real rule for what tips a field from green to yellow to red has not been defined yet — open architecture question for v1 build (likely Riccardo + Maurizio joint call).
Source linking
Each row carries a ⓘ DOC N · p.X chip pointing back to the document and page where the value was extracted. Clicking opens the source preview pane on the right. Per-typology quantity cells have their own chip when the count was read from a drawing.
DOC numbers are decoded in the legend banner under the classification strip (collapsible — click "Source documents").
Field grounding (where each value comes from)
- cited — value was extracted from a specific document + page (most row-level fields)
- inferred — value derived from context, no direct citation. Lower confidence by definition.
- default applied — EC internal standard used because the spec was silent (e.g. scarico, adduzione). UI affordance for this is not yet built; would render as a third state, neither flagged-missing nor fully cited.
Open decisions — questions for Maurizio
Nine questions Maurizio's input unlocks. Each shapes the v1 architecture. Even half-answers move the build forward.
B · Extraction — where does the AI pull info from?
- Posa when the client doesn't specify it. Audit of the 5 real descrittivi showed row 11 is empty for Progetto Demo A, Progetto Demo C, and Progetto Demo D — the client never specified. When that happens, where do you look it up? Project briefing? RFP cover note? Inferred from the drawings? Phone call to the client? Or doesn't it always matter at the descrittivo stage?
- Brand vs Model. When the project specification says only "lavabo Valdama," is Valdama the brand or the model? Do you have an internal convention to disambiguate, or does the estimator decide case by case?
- Per-typology quantities. Counts like "75 of T01, 213 of T02" — read from the drawings, derived from the client's BoQ, or applied as a rule (e.g. "one fixture per bathroom × N bathrooms")? We need to know where the AI should read those numbers.
- Project Specification language. [Partially resolved — Call 6] Output languages confirmed: IT, EN, FR, DE only. Swedish input → English output (Canta: "I've never seen a Swedish offer"). Norwegian: to confirm with Zanoni. Architecture question (extract-first vs translate-first) still open for Riccardo + build phase.
C · Conflicts between multiple sources
- Project Specification vs drawing — same item, different specs. When the project specification text and a pod drawing disagree on an item (e.g. the schedule says faucet model X, the accessible-bathroom drawing shows model Y), what's the current practice? Project Specification wins? Drawing wins? Do you flag back to the client? What would you want the system to do?
- Project Specification vs drawing — item in one but not the other. Different case: an item appears in the project specification but in no drawing (or vice versa). What do you do today? Include it anyway? Flag it?
- Revision diff. When a client sends Rev 01 after you've already worked Rev 00, would you prefer the system (a) figure out what changed and re-process only those parts, preserving the judgments already made, or (b) re-extract everything from scratch every time?
D · Defaults + operational rules
- Fields with internal EC defaults. In Call 4 you cited scarico and adduzione as fields where you apply "nostro standard" when the project specification is silent. What other fields do you regularly handle with an internal default? We need this to avoid the system raising false "missing field" alarms on them.
- Confidence rule (green / yellow / red). Each row in the mockup has a colored chip showing how confident the AI is. For now we've set them by hand to illustrate the UX. When we start building for real, what should tip a field from green to yellow to red? Number of text matches? Multi-way ambiguity? Missing citation? Your intuition here shapes the rule we design.
This list lives in the mockup itself so it's visible during pressure-test reviews instead of buried in call notes. Update as questions get answered.
Already resolved during the 2026-05-20 audit: structure detection (extract from xlsx row 18 directly — well-grounded in all 5 packages); section nav (real template is a flat 76-row list, no sidebar needed).
Confidenza per riga
Nota — questo mockup: i chip verde / giallo / rosso su ogni riga sono inseriti a mano nei dati demo per illustrare la UX. La regola reale che decide quando un campo passa da verde a giallo a rosso non è ancora definita — questione di architettura aperta per la build v1 (probabilmente call congiunta Riccardo + Maurizio).
Collegamento alla fonte
Ogni riga ha un chip ⓘ DOC N · p.X che punta al documento e alla pagina da cui è stato estratto il valore. Cliccando si apre il pannello di anteprima fonte sulla destra. Le celle quantità per tipologia hanno un chip dedicato quando il conteggio è stato letto da un disegno.
I numeri DOC sono decifrati nel banner di legenda sotto la striscia di classificazione (richiudibile — clicca "Source documents").
Origine del campo (da dove viene ogni valore)
- citato — il valore è stato estratto da un documento + pagina specifici (la maggior parte dei campi a livello riga)
- dedotto — valore derivato dal contesto, senza citazione diretta. Confidenza più bassa per definizione.
- default applicato — standard interno EC usato perché la specifica taceva (es. scarico, adduzione). Affordance UI non ancora costruita; verrebbe renderizzata come terzo stato, né mancante-segnalato né completamente citato.
Domande aperte — decisioni da prendere
Nove domande su cui ci serve il segnale di Maurizio per sbloccare la build v1. Anche risposte parziali fanno avanzare il lavoro.
B · Estrazione — da dove l'AI prende le info?
- Tipo di posa quando il cliente non la specifica. Guardando i 5 descrittivi reali, ho visto che in Progetto Demo A, Progetto Demo C e Progetto Demo D la riga 11 ("Tipo di posa") è vuota — il cliente non l'ha indicata. Quando capita, dove vai a recuperare l'informazione? Brief di progetto, cover dell'RFP, deduzione dai disegni, telefonata al cliente? Oppure a livello di descrittivo non sempre serve specificarla?
- Brand vs Modello. Quando il project specification dice solo "lavabo Valdama", Valdama è il brand o il modello? Avete una convenzione interna per disambiguare, o il estimator lo decide caso per caso?
- Quantità per tipologia. I conteggi tipo "75 pezzi di T01, 213 di T02" vengono presi dai disegni, dal BoQ del cliente, o c'è una regola tipo "un elemento per bagno × N bagni"? Voglio capire da dove l'AI dovrebbe leggere quei numeri.
- Lingua del project specification. [Parzialmente risolto — Call 6] Lingue di output confermate: IT, EN, FR, DE. Input svedese → output inglese (Canta: "non ho mai visto un'offerta in svedese"). Norvegese: da confermare con Zanoni. Domanda architetturale (estrai prima vs traduci prima) ancora aperta — da affrontare in fase di build con Riccardo.
C · Conflitti tra fonti multiple
- Project Specification vs disegno — stesso elemento, specifiche diverse. Quando il project specification testuale e un disegno di pod non concordano su un elemento (es. lo schedule dice rubinetto modello X, il disegno del bagno accessibile mostra modello Y), qual è la prassi oggi? Vince il project specification? Vince il disegno? Lo segnalate al cliente per chiarimento? Cosa vorreste che il sistema facesse?
- Project Specification vs disegno — elemento in uno ma non nell'altro. Caso diverso: un elemento è presente nel project specification ma non in nessun disegno (o viceversa). Cosa fate oggi? Lo includete comunque? Lo segnalate?
- Diff revisione. Quando un cliente vi manda Rev 01 dopo aver già lavorato il Rev 00, preferite che il sistema (a) capisca cosa è cambiato tra le due versioni e re-elabori solo quelle parti, preservando i giudizi già dati sul resto, oppure (b) re-estragga tutto da zero ogni volta?
D · Default e regole operative
- Campi con default EC interno. In Call 4 hai citato scarico e adduzione come campi dove applicate uno "standard nostro" quando il project specification non specifica. Quali altri campi del descrittivo lavorate regolarmente con un default interno? Ci serve per evitare che il sistema vi segnali quei campi come "mancanti" quando in realtà avete già un default che applicate.
- Regola di confidenza (verde / giallo / rosso). Nel mockup ogni riga ha un'etichetta verde/giallo/rosso che indica quanto l'AI è sicura. Per ora le abbiamo messe a mano per illustrare la UX. Quando partiamo a costruire davvero, cosa dovrebbe far passare un campo da verde a giallo a rosso? Numero di match nel testo? Disambiguità multipla? Citazione mancante? Sentire la tua intuizione qui ci serve per disegnare la regola.
Questa lista vive dentro al mockup stesso, così è visibile durante le review di pressure-test invece di essere sepolta nelle call notes. Da aggiornare man mano che le domande trovano risposta.
Già chiuse durante l'audit 2026-05-20: rilevamento struttura (estrazione diretta da riga 18 — ben fondata in tutti i 5 pacchetti); nav sezioni (il template reale è una lista piatta di 76 righe, nessuna sidebar serve).
| L. | Fit | Action |
Materiale (IT)
brand · model da capitolato · codici listino in Fase 2
|
custom
·
|
Cheaper alt. (EC) | Reg. | Note Aggiuntive | |
|---|---|---|---|---|---|---|---|---|
|
Da approvare
|
default applied
|
—
|
Propose alt.
|
— |
Pre-Quote ready
| Output file | 40 cols × 76 rows · 3 typology columns |
| Cells confirmed | green · yellow (estimator review) · red (flagged) |
| Language | Italian (estimator working language) |
| Cheaper alternatives | proposed (cheaper EC alternative) |
| Regulation profile | |
| Downstream | → Estimator (Phase 3 split + 34% markup) → Sales (Phase 4) — out of v1 scope |
Capacity note
1 estimator is the explicit bottleneck (call-notes.md:299). Today's pace: 2 / 4 descrittivi shipped to estimator. Faster Phase 1+2 → more full quotes vs budget estimates → conversion lift.
⚑ rows flagged from Phase 2
Read each BO note, then Resolve the row — confirm AI's brand+model, pick a substitute, or add a missing line. All flagged rows must be cleared before pricing the split. Pings to BO / Technical Office / Maurizio happen out-of-band; the estimator owns resolution either way.
Resolve options: confirm AI's brand/model, pick a substitute, or add a missing line. Per Maurizio's Call 4 feedback (2026-05-19), there's no separate "escalate" path in the system — the estimator owns the decision and pings BO / Technical Office / sales out-of-band when needed.
Pricing split — 11 sections
Today: ~3 hr per project · estimator works in Excel template, saves as locked PDF
| # | Section | Price source | Cost |
|---|---|---|---|
| Σ | Cost basis (somma sezioni) | — | |
| +R | Spese generali +34% (costo fisso interno — per flussocommerciale_AI.pdf) | Fisso | |
| = | Costo totale preventivato | → dir. commerciale | |
| K | K markup commerciale fissato da direzione commerciale — non dal preventivista | Fase 4 | applicato in Fase 4 → |
| CH | Ritenuta d'acconto (mercato svizzero) +2.5% da aggiungere al prezzo di offerta — la deducono in Fase 4 | Fase 4 | +2.5% in Fase 4 → |
What's manual here (and stays manual in v1):
- · Estimator fills lighting / mirrors / faucets / sanitary brand+SKU by hand.
- · Scocca + struttura priced from EC's internal factory costs.
- · Database lookups for supplier prices (valid if updated within last 6 months).
- · If price stale → request supplier preventivo, type in manually.
- · Locks the file as PDF on save to prevent mid-pipeline edits.
Commercial margin
Usual range: 3–5%. Above 5% requires direzione approval.
| Type | Unità | €/unità | Totale |
|---|---|---|---|
| Totale offerta | — |
Cost basis:
+ Estimator markup 34%: × 1,340
+ Margine commerciale %: ×
=
Reference: real EC offer (PDF)
The mocked preview above mirrors this offer's structure: cover, summary, per-typology pricing table, terms.
Open full PDF ↗Offer generated
· · · Margine
Download
Save the PDF locally before sending.
placeholder download not wired.
Send via email
Direct to client or via HubSpot (v2).
placeholder send not wired.
History
| Status | Code | Project | Customer | Country | Units | Last update | Reviewed by |
|---|---|---|---|---|---|---|---|
| No history matches. | |||||||
Real EC archive: ~240 RFQs / year, 3–4% conversion baseline, 40% fall back to "budget estimates". placeholder drill-down not wired.
v2 feature — not in v1 scope
In v1 the substitution table is imported as a CSV by the AdapttoAI team. This admin UI ships in v2 so Maurizio's ufficio tecnico can maintain it directly without going through us.
Substitution catalog
When the AI encounters a client-specified product, it checks this table and proposes EC's preferred alternative. Maintained by ufficio tecnico.
| Client specifies | EC proposes instead | Reason | Category | Actions |
|---|---|---|---|---|
| No rules match. | ||||