EVENTFLOW FE · TECHNICAL DOCUMENTATION · 07
Operational Architecture
EventFlow FE separates fiscal execution from operational observation. The fiscal transaction remains owned by the invoicing system and its SIFEN integration boundary; operational evidence is processed independently through a separate runtime boundary.
Architectural principle
Fiscal execution and operational observation are separate concerns.
EventFlow FE owns the electronic invoicing lifecycle within its fiscal environment: fiscal document preparation, electronic representation, digital signing, QR generation, submission to SIFEN, authority response handling and representation of the resulting fiscal status.
Operational evidence is observed outside that transaction boundary and processed independently by the runtime. A fiscal operation must not depend on the availability of the system that observes it. Operational analysis, persistence and recovery can evolve independently without changing the fiscal transaction path.
Two operational planes
Fiscal transaction plane
Owns the business and regulatory execution of electronic invoicing and progresses each document through the applicable SIFEN lifecycle.
- Fiscal document preparation
- Electronic document generation
- Digital signature
- QR generation
- SIFEN submission
- Authority response handling
- Fiscal status representation
Operational observation plane
Consumes operational evidence produced by the fiscal system through an independently bounded processing path.
- Operational evidence observation
- Independent runtime processing
- Persistent operational representation
- Idempotent processing
- Recovery across runtime executions
- Operational trace continuity
- Failure isolation from fiscal execution
Conceptual architecture
The public architecture is defined by three responsibility boundaries.
The diagram expresses architectural responsibility rather than internal implementation. Public contracts are defined through boundaries, observable behavior and validated guarantees.
Product Integration Layer
The Product Integration Layer preserves EventFlow FE domain semantics while presenting operational activity through stable runtime integration boundaries.
Fiscal concepts and execution remain owned by EventFlow FE. The integration layer observes relevant operational evidence and translates it for runtime processing without transferring ownership of invoice execution, SIFEN communication or fiscal authority responses.
This boundary keeps the shared EventFlow runtime architecture independent from fiscal protocols and product-specific implementations while EventFlow FE retains ownership of its fiscal rules.
Independent runtime boundary
The EventFlow Core Runtime consumes operational evidence through the product integration boundary and maintains processing continuity independently from EventFlow FE’s fiscal transaction lifecycle. Runtime processing can be durable, restartable and idempotent without requiring the original fiscal transaction to be executed again.
Responsibility matrix
| Responsibility | EventFlow FE | Product Integration Layer | Operational Runtime |
|---|---|---|---|
| Fiscal document creation | Owner | — | — |
| Digital signing and QR generation | Owner | — | — |
| SIFEN interoperability | Owner | — | — |
| Fiscal response handling | Owner | — | — |
| Operational observation | Source | Boundary | Processor |
| Domain translation | — | Owner | — |
| Durable runtime processing | — | — | Owner |
| Runtime idempotency | — | — | Owner |
| Runtime recovery | — | — | Owner |
Failure isolation
Runtime availability is not a prerequisite for fiscal document execution.
Failures affecting SIFEN communication belong to the fiscal transaction domain; failures affecting operational observation or runtime persistence belong to the operational runtime domain. Runtime recovery does not require fiscal execution to be repeated.
Technology independence
The architecture separates product domain semantics from transport, storage and runtime technologies. EventFlow FE remains specialized for its fiscal environment while the shared runtime operates through stable product integration boundaries.
SIFEN interoperability remains subject to the formats, security mechanisms and communication requirements of the Paraguayan electronic invoicing environment. Technology independence applies to the boundary between those product-specific requirements and the shared runtime architecture.
Public architecture boundary
This documentation exposes architecture through responsibilities, boundaries, observable behavior and validated guarantees. Proprietary runtime algorithms, internal knowledge-processing models, private state semantics, implementation-specific schemas and source-level runtime composition remain outside the public specification.