# Parameter workspace and application delivery Implemented checkpoint updated 26 September 2026. Portal → authenticated gRPC → Dapper → SQL Server 2022; Android UIC Home 3.9.14-dev uses the read-only provider and Linux xTMSAgent uses the parameter file bridge. Schema `group` values render related fields together. No legacy UIC Connect project dependency. ## Operator workflow 1. Open **Parameters** in the sidebar, select a customer and create a schema name (for example PAYAPP), or import a UIC Connect schema export. 2. The editor shows device tables as an indented tree with connector lines, parent names and one/many-per-parent badges. Shared catalogs appear separately. Expand any table to edit its fields, or use Add child table to preselect that parent. Add shared catalog tables and child device tables. Edit fields, required/key flags, types, defaults, options, catalog references, validation and row/column/span. Preview uses the device form renderer. Tables and fields have a single Label, authored in the language chosen by the bank. The same label is shown in every portal language. 3. Optionally configure the consuming Android package and/or signing certificate SHA-256. Blank values independently skip those restrictions; device authentication and customer/device scoping remain mandatory. Save the schema. It stays editable under the same name. 4. Open **Shared catalogs**, create/edit/delete records and **Save**. Reference selectors use the current saved catalog. 5. Choose **Device parameters**, select a terminal and start empty or from a template. Add Terminal, Acquirer and Issuer records, then **Save**. There is no Publish action or visible revision lifecycle. 6. Every save validates required values, types, keys, parents and references. A schema or catalog change also validates existing dependent configurations in the same transaction. Breaking changes are rejected with the affected configuration name and validation reason. 7. **Save as template** and **Copy to device** use the current saved values. Copying saves the replacement immediately, with confirmation before overwriting an existing target. Review merchant/terminal identifiers before copying. Templates are independent after creation. ## Current data and download compilation The current `Json` in each customer-scoped schema, catalog, template and device document is authoritative. Existing records use their last saved content without a republishing migration. Internal counters support optimistic concurrency and audit history, but are not displayed as user-facing versions. Legacy Published fields remain in the database/protobuf for compatibility; they do not govern availability. The obsolete Publish request flag is ignored. On every authenticated download the service reads the current device configuration, schema and shared catalogs in one serializable transaction, rechecks device ownership and assignment epoch, enforces the current schema's application restrictions, validates the records and compiles the response. No stored published snapshot is used. Invalid legacy configurations cannot be downloaded until corrected and saved. The payload retains `format: uic-tms-parameters`, `formatVersion: 1`, `schemaName`, `deviceId`, `assignmentEpoch`, `schema`, `catalogs`, and `rows` with row IDs and parent IDs. Internal `revision`, `schemaRevision`, and `catalogRevision` fields identify the inputs for diagnostics. Consumers should compare the SHA-256 of the complete response, not just the device counter, because shared data can change independently. Saved schema/catalog changes appear on the next request without resaving each device. The existing SHA-256 response header covers the freshly compiled bytes. Save makes data available; it does not mean the payment application has downloaded or applied it. The Android provider protocol is unchanged. ## Android payment app contract UIC Home exposes a read-only ContentProvider, authority `.parameters`. Make the call from a background worker, not the application UI thread: ```kotlin val uri = Uri.parse("content://com.uic.tms.home.uic.newpos.debug.parameters/PAYAPP") val parameters = context.contentResolver.openInputStream(uri)!!.use { it.readBytes().toString(Charsets.UTF_8) } // Parse and validate schemaName and response hash; transactionally apply to the payment database. ``` Use the production Home package authority for release builds. Android package visibility declarations may be required for provider discovery on the consuming application. Home obtains the caller UID from Binder, resolves its installed package and signing certificate, and sends those with enrolled device credentials to the HTTPS parameter endpoint. Caller-provided identities are not accepted. The service independently checks each nonblank package/certificate restriction in the current saved schema. Blank restrictions do not disable device authentication. Shared UIDs and multi-signer APKs are rejected in this checkpoint. Downloads reuse the enrolled server certificate trust and normal hostname verification. Redirects are disabled; requests and responses are bounded. Home checks the snapshot hash, device, assignment epoch and schema name, writes the complete response atomically to a private temporary file and shares only the validated response through a reliable pipe. Enrollment secrets never leave Home. Failures close the pipe with an error; the application must retain its prior configuration and retry. There is no offline-cache fallback or application-applied acknowledgement yet. ## Supplied PAYMENT_APP example The schema imports successfully: nine tables and 223 fields. It has four shared catalogs and five device tree tables. PAYMENT_APP is saved for BANPAIS. The supplied data export has 26 catalog records and no device records. Its EMV data contains 27 fields absent from the attached schema (25 contactless and two contact), and one populated encrypted field. Import validation reports unknown fields and unsupported secrets instead of silently discarding data. Reconcile those fields in the saved schema; remove secret values from a working import copy, preserving the original file. Legacy `default_from`, `value_from` and `inheritable` metadata are retained as reference metadata, but no external bank/lane lookup or legacy UIC Connect inheritance is executed. Explicit values are required in TMS. Nonempty legacy tree-record imports are rejected because their parent-identity conversion needs a defined mapping; native UIC exports preserve row IDs and parent relationships. ## Current boundaries - Secret/encrypted fields are retained in definitions but nonempty defaults/values are rejected. The editor asks before removing secret defaults on import. No payment-key provisioning, secret vault or masked-secret editing is claimed. Treat ordinary text fields as nonsecret; do not place credentials in them. - Schema version cloning uses a distinct name. Automated migration, rollback UI, draft autosave, drag-to-resize, field-level diffs, scheduled parameter push and application-applied receipts remain later work from the design baseline. - Fixed limits: 1 MiB input, 64 tables, 1,024 fields, 5,000 records per table/device document, bounded JSON nesting and 50 ms regular-expression validation timeout. Workspace lists are intended for this development checkpoint; large-bank pagination is not yet implemented. - Desktop/mobile layouts and English/Spanish controls are provided. Custom schema labels always use the supplied Label, independent of the portal language. ## Validation and local environment 160 integration checks passed, including tenant/device isolation, immutable schemas, draft visibility, snapshot hashing, signer authorization, catalog pinning, stale edits, templates, invalid parents and unknown fields. NEWPOS and NEXGO APK builds compile. The physical device was not connected to ADB during this checkpoint, so IPC on the actual payment application remains unverified. SQL Server reported OS error 21 / SQL error 823 for the existing `UICConnectTMS_IntegrationTest` files. The main `UICConnectTMS` database passed `DBCC CHECKDB ... PHYSICAL_ONLY`; migration 005 was applied. The original test database was retained. Tests were run against a fresh `UICConnectTMS_ParametersTest` database: ```powershell ./scripts/Test-Integration.ps1 -TestDatabase UICConnectTMS_ParametersTest ``` The original test database's storage issue still needs investigation; no repair/data-loss operation was performed. ## Portal dialog convention Use the shared `window.uicConfirm(message, options)` styled modal for confirmations. Publish, deletion, import cleanup, draft replacement and unsaved-change navigation all use it. Cancel and Escape leave the action untouched; focus returns to the triggering control. Do not introduce native `alert`, `confirm`, `prompt` or `beforeunload` dialogs. Browser close/reload cannot show custom asynchronous confirmation; save drafts before closing or reloading. Portal link/form navigation is guarded with the styled discard dialog. Form constraint errors render inline, with accessible descriptions, instead of native validation bubbles.