Security & architecture

Trust is an architecture decision.

Regulated retail software gets judged on the day something goes wrong. These are the structural choices that determine how that day goes — described plainly, so you can ask hard questions on the call.

Tenant isolation in the data layer

Isolation is enforced where the data lives rather than by remembering to add a filter in application code. A missing predicate returns nothing, not someone else's rows.

Policy-based authorization

Authorization decisions are evaluated against explicit policy rather than scattered conditionals, so what a role can do is something you can read rather than infer.

Tamper-evident audit

Audit events are canonicalized, Merkle-rooted, signed, and chained to the previous anchor. Verification recomputes the root, so an altered history fails the check.

Device enrollment and binding

Terminals enroll with proof of possession and bind to a store. A device removed from the floor is not a working register somewhere else.

Resilience as a design constraint

Offline operation, local queuing, and idempotent replay are part of the transaction model, which is why reconnecting reconciles rather than duplicates.

Durable, ordered events

Operational activity is published through a transactional outbox, so an event is either committed with its transaction or not at all.

Verifiable audit

You should not have to trust the vendor's word.

Most audit logs are a table the vendor can edit. Ours is a hash chain: each anchor commits to a Merkle root over its events and references the previous root. Recomputing the root is how you check it, and a mismatch is a failure rather than a warning.

  • Events canonicalized to a stable encoding before hashing
  • Anchors signed and linked to the prior root
  • Verification recomputes rather than trusting the stored value
  • Exportable, so the evidence leaves with you
AUDIT ANCHOR CHAIN Root verified
  1. ANCHOR 0041214:02:11Z
    events1,284 events
    prev root6b81…dd03
    merkle root9f2c…a417
  2. ANCHOR 0041314:32:11Z
    events1,097 events
    prev root9f2c…a417
    merkle rootc740…1e9b
  3. ANCHOR 0041415:02:11Z
    events1,411 events
    prev rootc740…1e9b
    merkle root3ad5…77f2
recomputed3ad5…77f2matches
Illustration of three sequential audit anchors, each referencing the previous Merkle root, with the latest recomputed root matching the stored value.

Engineering practice

The habits underneath the claims.

Architecture only holds if the day-to-day discipline does.

  • Secrets are managed centrally and never committed to the repository
  • Contract tests gate API changes so integrations break in CI, not in production
  • Money paths are idempotent by construction, so a retry is not a second charge
  • Deterministic engines for limits and financial calculation, with their own test suites
  • Request, tenant, terminal, and actor identifiers are carried through for traceability
  • Generated artifacts are produced by generators, keeping schema and code in agreement

SMOKESTACK is pre-general-availability and we are not going to claim certifications we have not completed. If your procurement process needs specific attestations, raise it early and we will tell you honestly where we stand.

Bring your hardest questions.

Security review, architecture deep-dive, or a walkthrough of how the audit chain verifies — we would rather have that conversation than a feature tour.