Operating Lerian SILOC

​

Settlement windows

​

Regulated certificates

​

Contingency and recovery

• An undecodable envelope, a decoded message without a nonblank BCMSG.NUOp, or an unsupported (CodProdt, CodMsg) pair fails closed to an operator exception. The service does not support LDL0020 and LDL0006, and never relays them as settlement funding.
• SLC relay is at-least-once. For a successfully decoded SLC funding frame, the service checks durable deduplication by BCMSG.NUOp before relay and writes the processed-message record only after relay succeeds. This is not message-ID-only deduplication and is not an unconditional end-to-end exactly-once guarantee.
• Parked and refused messages. GET /api/v1/siloc/dlq/deferred lists the inbound messages parked for replay. Filter with status=SEMANTIC_REJECTED for the messages the service refused on their content and never applies.
• Quarantined frames. GET /api/v1/siloc/dlq/quarantine lists the frames moved to the backout queue. After you deal with the copy on that queue, resolve the frame. The service does not feed it again, and it clears INBOUND_QUARANTINED when no unresolved frame remains.
• Relay failures. GET /api/v1/siloc/dlq/relay-failures lists the funding frames parked during a relay outage. Replay a frame after the relay recovers. A replay of a BCMSG.NUOp already relayed resolves the frame without a second relay.

​

Reconciliation

• Processed-message dedup ledger. For successfully decoded SLC funding frames with a nonblank NUOp, the ledger uses BCMSG.NUOp and records it only after a successful relay. Undecoded and unsupported messages do not receive a processed-message record.
• Relay audit feed. The relay feed lists the funding messages that the service relayed to Lerian SLC.
• Per-participant status and status history. Each participant carries its operational status per product. The service records each status change as a status-event history entry.
• OT cycle reconciliation. With RECONCILE_ENABLED=true, the service compares each cycle with its final ROC and settles a cycle whose ROC matches its settled instruction.

​

Monitoring, alerts, and audit

• OT settlement cycles. GET /api/v1/siloc/cycles and GET /api/v1/siloc/cycles/{cycleId} list and inspect cycles. GET /api/v1/siloc/cycles/{cycleId}/reconciliation returns the reconciliation result, and GET /api/v1/siloc/cycles/{cycleId}/recalculations returns the cycle’s recálculo round chain, including each round’s complement/deposit window closure.
• Settlement instructions. GET /api/v1/siloc/settlement-instructions and GET /api/v1/siloc/settlement-instructions/{instructionId} return each cycle’s obligation legs. POST /api/v1/siloc/rocs ingests a semantic ROC revision. It accepts the rail’s semantic ROC format, not a Núclea ROC file, and a revision supersedes prior values for the cycle.
• Outbound requests. GET /api/v1/siloc/outbound/messages lists the requests the institution sent, newest first. Filter by status: the service cannot deliver a FAILED request as stored, and that request needs an operator. A REFUSED request came back from Núclea with an error.
• Operational alerts. GET /api/v1/siloc/alerts returns an active-only, keyset-paged feed. Pass activeOnly=false to include deactivated alerts as history. The alert types are:
  • Settlement cycle: WINDOW_CLOSING (a deposit/complement deadline approaches), RECALCULATION (a cycle is in a recálculo round), and SCHEDULE_CHANGE (an operator recorded a contingency schedule announcement).
  • Connection and workers: CONNECTION_DOWN, RELAY_DOWN, CERTIFICATE_EXPIRY, OUTBOUND_DISPATCHER_DOWN, OT_REPLAY_DOWN, and XSD_VALIDATOR_DOWN.
  • Câmara notices: CAMARA_CLOSED, CAMARA_INTERRUPTED, COLLATERAL_REQUIRED, COLLATERAL_SUBSTITUTION, and ELIGIBLE_ASSETS_CHANGED.
  • Inbound messages and requests: INBOUND_QUARANTINED, INBOUND_SEMANTIC_REJECTED, FOREIGN_TENANT_COMMAND, and UNANSWERED_REQUEST.
• Alert acknowledgement. POST /api/v1/siloc/alerts/{id}/acknowledge records that an operator saw the alert, with an optional note of up to 500 characters, and moves the alert to history. It does not end the condition. When the service checks an alert on a schedule, such as RELAY_DOWN, it raises the alert again while its condition holds. An alert that is already inactive answers 409. INBOUND_SEMANTIC_REJECTED and FOREIGN_TENANT_COMMAND close only by acknowledgement. A condition alert, such as RELAY_DOWN or RECALCULATION, also clears when its condition resolves. For example, a cycle that settles clears its RECALCULATION alert on the settle path.
• Homologation scenarios. GET /api/v1/siloc/homologation/scenarios lists the certification scenarios and the status of each. Running a scenario checks its pass criterion against the rail’s own state and records the evidence. It sends nothing to Núclea.
• Audit trail. GET /api/v1/siloc/audit-records returns a paged, verbatim read of the audit trail, for example to export the record of an operator action or a participant status change. Bounds from and to are RFC3339 instants (the service rejects date-only values).

​

Schedule and contingency

• Calendar and windows. GET /api/v1/siloc/schedule/calendar returns the business-day calendar, and GET /api/v1/siloc/schedule/windows returns the compiled canonical OT window grid. The grid is a static artifact, not a per-day read, and the service returns it even when the datastore is down.
• Câmara grids and session. GET /api/v1/siloc/schedule/grids returns the schedule grids Núclea sent, from its change advices and from the answers to the institution’s schedule queries. GET /api/v1/siloc/schedule/camara-session returns the latest opening, closing, interruption, and resumption notices. The active CAMARA_CLOSED or CAMARA_INTERRUPTED alert tells you whether the câmara is closed or interrupted.
• Contingency schedule changes. POST /api/v1/siloc/schedule/changes records a contingency announcement the operator received out of band from Núclea. The body carries reason (≤500 chars), origin (the announcing channel or upstream reference, ≤256 chars), effectiveAt, the announced RFC 3339 instant the change takes effect, and an optional windowSeq naming the affected canonical window. With windowSeq, effectiveAt becomes that window’s deposit close for WINDOW_CLOSING. The record is append-only: a later announcement never rewrites an earlier one. The newest announcement does become the single active SCHEDULE_CHANGE alert. Recording one clears the prior alert and raises a new one whose deadline is effectiveAt verbatim. GET /api/v1/siloc/schedule/changes returns the recorded changes, newest first.

curl -X POST https://siloc.example.com/api/v1/siloc/schedule/changes \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency: 2026-07-22-window-2-extension" \
  -d '{
    "reason": "Núclea extended the OT window by 30 minutes",
    "origin": "Núclea e-mail ref 2026-07-22/01",
    "effectiveAt": "2026-07-22T16:20:00-03:00",
    "windowSeq": 2
  }'