Government Integration Layer

Purpose & Design Principles

VisaChief.com prepares and manages visa applications. At the point of lodgement, and thereafter for status and requests for further information, the platform must exchange data with a department's visa processing system. The Government Integration Layer is the single component that performs that exchange.

It exists so that the department integrates with one hardened, contract-bound, independently assessable interface - never with the platform's internal services, and never with an AI component directly.

Design principles

• One door. All departmental traffic passes through the integration layer. No other VisaChief component may open a connection to a departmental endpoint.
• The department controls its own ingress. We connect on the department's terms - its gateway, its allow-list, its throttles, its certificate policy. We hold no credential capable of writing directly to a departmental data store.
• Deterministic boundary. Everything crossing the boundary is produced by deterministic code against a validated schema. AI-assisted output is reviewed by a registered migration agent before it can be packaged for lodgement.
• Signed, versioned, idempotent. Every payload carries a schema version, a signature and an idempotency key, so a retry can never create a duplicate case.
• Evidence by default. Every exchange writes an immutable audit record that the department can read, export and reconcile against its own logs.
• Sovereign by construction. The layer runs only in Australian regions; region pinning is enforced by policy-as-code, so a deployment elsewhere fails at the control plane.
• Degrade safely. If the department is unavailable, work queues durably and replays in order. Nothing is silently dropped and nothing is lodged twice.

Reference Architecture

Reading left to right: the people and systems that originate work, the VisaChief platform that prepares it, the integration layer that packages and transmits it, and the departmental environment that assesses and decides.

• Every cross-boundary call is mutually authenticated with certificate pinning; payloads are signed, versioned and idempotent.
• The department controls its own ingress. VisaChief holds no credential that can write directly to a departmental data store.
• Personal information never leaves Australian regions; the integration layer is the only component permitted to egress to the department.

Component Specification

Each element of the integration layer has a single responsibility, so that a control can be tested in isolation and a failure has a bounded effect.

Network Topology & Zones

The deployment view matters as much as the logical view: it is what determines whether a compromise in one zone can reach applicant data or the departmental link.

• Segmentation is default-deny: each zone may reach only its declared dependencies, enforced by network policy rather than convention.
• The data zone has no route to the internet. Document and case data can only be read through the application zone's authorisation checks.
• The integration egress zone holds the departmental certificates and is the only zone with an allow-listed route out. Compromise of the edge or application zone does not yield the ability to transmit to the department.
• Administrative access to any zone is just-in-time, peer-approved and session-recorded; there is no interactive shell in production.
• Outbound egress from production is allow-listed to the department endpoint and a small set of named services. Inbound connections from the department are accepted only if the department elects the callback pattern; otherwise the integration layer polls and no inbound path exists at all.

Lodgement Data Flow

The sequence below is the standard path for a prepared application. Each numbered step writes an immutable audit record that the department can read and reconcile.

Integration Patterns & Protocols

Interconnect Options

The department elects the connectivity model. All three carry identical application-layer controls - mutual TLS, signed payloads, idempotency and full audit. They differ only in network exposure and lead time.

Security Controls at the Boundary

The controls below apply to every exchange regardless of pattern or interconnect. Full platform security is documented in the companion Security & Data Protection Dossier.

Schema & Reference Data Governance

Immigration rules change frequently. The integration must absorb that change without silent divergence between what the department expects and what we send.

• Explicit versioning. Every payload states its schema version. The department's supported versions are configured, not inferred.
• Additive change by default. New optional fields do not break existing consumers. Breaking changes require a new major version and a negotiated migration window.
• Contract testing. Schema conformance runs in our build pipeline against the department's published contract; a violation fails the build rather than reaching production.
• Code tables are pulled, not hard-coded. Visa subclasses, document types, fee schedules and country codes are synchronised from the department's reference data with a stated version.
• Reproducibility. Because outputs are tied to a pinned reference-data version, any past submission can be reproduced exactly as it was assembled.
• Change notification. The department is notified before we adopt a new schema or reference-data version in production, and either party may pause adoption.

Compatibility policy

Environments & Conformance Testing

Conformance suite

• Happy-path lodgement across each visa product in scope, verified end to end against the department's acknowledgement.
• Negative cases: schema violation, oversized document, unsupported document type, missing mandatory evidence - each must be rejected cleanly with an actionable error.
• Failure injection: department endpoint unavailable, slow response, partial failure mid-batch, duplicate submission - verifying queueing, ordered replay and idempotency.
• Security tests: expired certificate, revoked certificate, invalid signature, replayed nonce, sandbox credential against production - all must fail closed.
• Reconciliation: a full day of traffic reconciled line-by-line between our audit log and the department's records, with a required zero-variance result before cutover.

No environment is promoted without documented exit criteria signed by both parties. Non-production environments never contain live personal information.

Error Handling & Reconciliation

The design principle is simple: fail loudly, never silently, and never twice.

A daily reconciliation compares our audit log against the department's acknowledgements and flags any variance for investigation within one business day. The reconciliation report is available to the department.

Observability, Audit & Evidence

• Immutable exchange log. Every request, response, retry and acknowledgement is written to append-only storage with independent retention. Production credentials cannot alter or delete it.
• Department access. The department may subscribe to, or export, the audit records relating to its own integration - so it can reconcile against its records without relying on our assertion.
• Provenance. Each submission records the case, the agent who signed off, the schema and reference-data versions used, and the exact payload hash, so any past submission can be reproduced.
• Metrics. Volume, latency, error rate, retry rate and queue depth are reported against the performance targets below.
• Alerting. Certificate expiry, signature failure, authorisation failure, queue-depth growth and reconciliation variance all raise operational alerts with defined escalation.
• Incident notification. Any security incident affecting the integration is notified to the department within 24 hours of confirmation, with updates at agreed intervals.

Performance & Availability Targets

Targets are set at design authority review against the department's expected volumes; the figures below are the standard commitments in the absence of agreed alternatives.

Responsibilities at the Boundary

Clear demarcation prevents the gaps where incidents happen.

Onboarding & Assurance Path

Each gate has documented exit criteria signed by both parties. No gate is skipped, and volume is capped until the final gate closes.

Assumptions, Dependencies & Open Items

Stated plainly, so that design authority review starts from an accurate position rather than an optimistic one.

Indicative Interface Surface

Representative only. The binding surface is the department's published specification; where none exists, we propose the following as a starting point for design authority review.

Glossary

Companion document: Security & Data Protection Dossier (Government Edition).