Inizia dal record. Mantieni esplicito il contratto.
Esplora il modello di evidenza e i confini di integrazione prima di collegare un workflow rilevante.
01 / MODELLO DI EVIDENZA
Un record che un revisore può seguire.
Un record di evidenza utile collega sorgente, contesto, policy e riferimento autorevole alla ricevuta. L’esempio seguente è esplicativo. Non è uno schema pubblicato di richiesta API.
evidence-example.json
{
"record_kind": "illustrative_example",
"tenant_scope": "demo-workspace",
"source": "Fonte di esempio (solo illustrativo)",
"context": [
"Contesto di esempio (solo illustrativo)"
],
"policy": "Support escalation v3.2",
"receipt_reference": "demo_rct_7v2a\u2026e91c",
"verification_status": "not_a_live_receipt"
}
Il materiale acquisito come evidenza e il riferimento necessario per ispezionarne l’origine.
Contesto
Materiale recuperato e configurazione disponibili per il workflow registrato.
Policy
L’identificatore o la versione della policy associati all’evento.
Riferimento ricevuta
Un identificatore autorevole restituito dal backend di evidenza, mai inventato da un frontend di produzione.
Ambito tenant
L’identità del workspace applicata dal backend autenticato. Un valore fornito dal client non autorizza l’accesso.
03 / CONFINI DI INTEGRAZIONE
Prima l’identità, poi l’evidenza.
L’architettura di prodotto di PHIROK include confini MCP e gRPC protetti. Autenticazione, ambito tenant e gestione autorevole delle ricevute fanno parte del contratto di integrazione.
Risolvi l’identità dal contesto backend autenticato.
Tratta una conservazione non riuscita come un errore, non come una ricevuta verificata.
Recupera i record tramite identificatori autorevoli.
Mantieni disponibili il materiale sorgente e il suo contesto di verifica.
Mantieni le fixture di test separate dall’evidenza di produzione.
Prima di integrare
Ottieni endpoint, requisiti di autenticazione e contratto API versionato per la tua distribuzione. Questo sito non pubblica né ipotizza questi dettagli.
04 / VALUTAZIONE
Rendi osservabili i criteri di accettazione.
CASI 01–03
Conservazione e ripristino
Verifica che l'evidenza sia conservata, recuperata con provenienza e sopravviva a un riavvio.
01
Conserva → ispeziona
Scrivi l’evidenza, ottieni una ricevuta autorevole e risalvi al record conservato.
02
Recupera → provenienza
Conferma che la ricerca restituisca evidenza tracciabile invece di sostituti generati.
03
Riavvia → recupera
Verifica lo stato conservato e la ricerca delle ricevute nelle procedure di ripristino della tua distribuzione.
CASI 04–05
Isolamento ed errori
Verifica l'isolamento tra workspace e che gli errori producano esiti espliciti.
04
Tenant A → Tenant B
Verifica che un workspace autenticato non possa accedere all’evidenza di un altro workspace.
05
Errore → esito esplicito
Ispeziona il comportamento con input non validi, storage non disponibile e accesso non autorizzato.
No. PHIROK è presentato come piattaforma di memoria verificabile ed evidenza. Il suo retrieval non generativo restituisce evidenza che un altro sistema o un revisore può usare.
Una ricevuta può provare cosa stava “pensando” un’AI?
Una ricevuta può vincolare evidenza e contesto registrati. Non rivela il ragionamento interno privato di un modello né stabilisce che ogni input disponibile abbia causalmente influenzato un output.
Sono disponibili embedding commerciali di produzione?
L’attuale livello semantico è descritto con fixture di test deterministiche. Questo sito non pubblicizza embedding commerciali di produzione come funzionalità disponibile.
Dove può leggere il sito un agente?
Il contenuto principale è presente in semplice HTML. Una concisa panoramica Markdown e un brief tecnico completo forniscono un formato di lettura aggiuntivo. Non sostituiscono la documentazione API della distribuzione.
LA TUA PROSSIMA DECISIONE
Costruisci sul record. Mantieni esplicito il contratto.
Parti dal modello di evidenza, prepara un brief di valutazione e integra un flusso consequenziale.