Models and prompts
Model calls, responses, reported usage, and the name and version of the prompt template.
Product
AI transaction records and evidence review
Sigillum Finans records AI-enabled financial workflows and connects their model, document, rule and service activity. Technology, risk and audit teams can review the basis of a transaction within the institution’s own environment.
01 / AI traceability
From model call to transaction outcome
A financial workflow can involve model calls, document retrieval, business rules, service responses and human intervention. Sigillum Finans brings records of these steps together under a shared transaction context within the configured recording scope.
Model inputs and responses, prompt templates, document and rule versions, and action outcomes can be reviewed together. HTTP exchanges and message deliveries are linked to the business steps reported by the application.
Documents and rules
Retrieval results, document identifiers and versions, and references to the rules and policies applied.
People and actions
Human review, authorization, action requests and completion records.
ARCHITECTURE VIEW / 02
Review a response in its transaction context
Model, document, service and human-intervention records are linked within the same transaction. Review uses the reported information and the recording scope defined for that transaction.
RECORDS LINKED TO THE TRANSACTION
MODEL / PROMPT
Model call
Request, response and model identity
Reported prompt and version details
RAG / RETRIEVAL
Knowledge sources
Retrieved document references
Reported document versions
ONE TRANSACTION CONTEXT
Steps and relationships
Request → decision process → outcome
Declared relationships between calls
TOOL / SERVICE
Tool and service calls
Dependency responses
Input, output and call relationships
OVERSIGHT / OUTCOME
Human intervention
Reported review and decision
The application’s outcome record
SIGILLUM REVIEW
Provenance · Integrity · Coverage
Record basis, signature verification and expected information
01
Record provenance
Service statements, observer reports and information derived from sealed HTTP exchanges retain distinct provenance.
02
Version references
Model, document and rule references connect to the institution’s registries. A stored reference can be retrieved again for comparison.
03
Defined recording scope
Expected events, fields, services and start-to-outcome records are compared with received records. Gaps appear on the transaction.
02 / Transaction review
Review records in context
The portal presents transaction flow, service relationships, HTTP exchanges and message activity together. Teams can move from a transaction to an individual record, its content and verification results.
The recording scope defines expected services, events and fields. Review compares incoming records with this definition and identifies missing fields or conflicts. The scope version used for a transaction is fixed at its first acceptance.
Record provenance
Service statements, observer reports and information derived from sealed exchanges are identified separately.
Scope checks
Expected records and fields are assessed against the scope version assigned to the transaction.
Integrity and witness
Record integrity and comparison with the separate witness record can be reviewed together.
TRANSACTION RECORD EXAMPLEIllustrative example
Records linked to one transaction
CONTEXT & REFERENCES↗
Documents and policies used
Review the document, policy and service responses recorded for the transaction, with their version references.
- Document
- Credit assessment policy
- Reference
- Version and content hash
- Record origin
- Service declaration
Retained references show which version was recorded at the time of the decision.
An illustrative example of how it works: review a request, its supporting records, model response and outcome within the institution’s configured recording scope.
03 / Version references
Model, document and rule versions
A named model, document or rule version can be queried from the institution’s registry. The returned descriptor, content hash and version information are sealed as a reference.
When a historical reference is queried again, the new response is compared with the recorded response. A changed descriptor or content hash for the same version appears as a separate finding, giving teams a history of the supporting references.
04 / Team workflows
Investigations, alerts and follow-up
Technology, risk and audit teams review the institution’s applications through a shared portal. Transactions can be grouped into investigations, with assessments, notes and related evidence retained in a recorded workflow.
Central alert rules monitor record, integrity, witness and operational conditions. The institution defines thresholds, severity levels and notification channels; assignment, review and closure are retained in the alert history.
05 / Record integrity
Signed records and offline verification
Evidence records are persisted, protected by signed receipts and compared with a separate witness record. Corrections are appended to the chain with a link to the earlier record.
Transaction evidence and a witness excerpt can be exported together. Offline tools check signatures, content hashes and chain links against public keys trusted through an independent channel.
06 / Retention and archives
Manage the evidence lifecycle
Retention policies define the period, starting conditions, approvals and exceptions. Holds retain the relevant records; authorized disposal is documented through receipts, hashes and a disposal certificate.
S3-compatible archive transfer, separate archive custody, timestamps and long-term preservation tools work with the institution’s storage infrastructure. Encrypted portable exports provide institutional data together with its verification information.
PRODUCT INFORMATION
Frequently asked questions
Who uses Sigillum Finans?
The product serves technology, risk and audit teams that build and review AI-enabled financial workflows. Model calls, supporting references, service activity and record integrity can be assessed in the same review environment.
How are model responses recorded?
Services report model records through the SDKs. The installation also produces model records from successfully completed generative HTTP exchanges mapped to OpenAI Chat Completions, OpenAI Responses and Anthropic Messages formats. Application-specific information, such as a prompt template’s name and version, is added through service records.
How is a transaction’s recording scope determined?
The application’s recording scope defines expected services, event types and fields. The scope version associated with a transaction at first acceptance is retained throughout review. The portal shows how its records meet that scope and identifies their provenance.
How are evidence packages examined?
Transaction evidence and a witness excerpt are exported together. The offline verifier checks signatures and chain links using trusted public keys obtained through an independent channel. The review can be performed without a running product server or user account.