CDG / ENGINEERINGContactSign in ↗

Platform Engineering

Northstar Atlas / El Sembrador Ecosystem

A current synthetic demonstration of the full ecosystem I built at El Sembrador: connected business workflows, governed data changes, warehouse execution, dispatch, delivery, identity, and infrastructure.

Current synthetic demonstration / private implementationoriginal systemsource only

ORIGINAL CONTRIBUTIONS

What I built.

  • At El Sembrador, designed and built the full operational ecosystem from applications and data flows through cloud architecture, local compute, and deployment.
  • Built the current Atlas demonstration around separate Go API and worker processes, a React/TypeScript client, PostgreSQL persistence, and API-enforced identity roles.
  • Made product approval, audit recording and outbox insertion one transaction, with explicit stale-version checks and retry-safe downstream handling.
  • Connected order, warehouse, shipment, document, dispatch and delivery journeys through stable record identities and controlled state transitions.
  • Created one sanitized architecture model, synthetic staff/operations experiences, and map-based dispatch visualization for public inspection.

Northstar Atlas / El Sembrador Ecosystem / SYSTEM MAP

How this system connects.

Staticexplorer1RESTAPI2PostgreSQL3Authentik4Approvalmodule5Transactionaloutbox6Integrationworker7Demointegration8Orders &warehouse9Documents &PDFs10Replenishment11Syntheticexchange12Profiles &operational threads13Timekeeping &supervision14Routing &dispatch15Driveroperations16Simulated monitoring& alerts17Persistedanalytics18
  1. Static explorer: Make the ecosystem and its trust boundaries inspectable.
  2. REST API: Coordinate business workflows through a Go HTTP API.
  3. PostgreSQL: Retain business state, revisions, evidence and delivery progress.
  4. Authentik: Delegate user authentication to a dedicated identity provider.
  5. Approval module: Publish product changes through independent review.
  6. Transactional outbox: Keep approved changes and their integration events consistent.
  7. Integration worker: Process persisted integration work outside request handling.
  8. Demo integration: Demonstrate integration receiving and durable acknowledgments.
  9. Orders & warehouse: Connect orders to stock reservations, pick/pack and shipments.
  10. Documents & PDFs: Turn persisted business records into revisioned documents.
  11. Replenishment: Review supply requests with clear ownership and authority.
  12. Synthetic exchange: Connect fictional partner messages to real persisted workflows.
  13. Profiles & operational threads: Keep operational conversations connected to business context.
  14. Timekeeping & supervision: Connect employee identity, time records and reviewed corrections.
  15. Routing & dispatch: Turn persisted shipments into executable delivery plans.
  16. Driver operations: Record ordered delivery progress under current assignment.
  17. Simulated monitoring & alerts: Translate fresh route observations into actionable exceptions.
  18. Persisted analytics: Explain operations through traceable, consistent measures.
Directed connections
  • 1 → 2: Authenticated REST (implemented)
  • 2 → 3: Approved catalog and workflow persistence (implemented)
  • 1 → 4: OIDC + PKCE (implemented)
  • 2 → 4: Verify access tokens (implemented)
  • 2 → 5: Authorize approval (implemented)
  • 5 → 6: Atomic transaction (implemented)
  • 7 → 3: Leases, retries and receiving transactions (implemented)
  • 7 → 6: Claim and retry events (implemented)
  • 7 → 8: Duplicate-safe delivery (implemented)
  • 2 → 9: Authorize orders and warehouse commands (implemented)
  • 9 → 3: Atomic reservations, stock and shipment history (implemented)
  • 9 → 10: Shared order, product and shipment identifiers (implemented)
  • 10 → 3: Draft revisions and immutable issued PDFs (implemented)
  • 9 → 11: Product-linked requests; no automatic stock receipt (implemented)
  • 11 → 3: Persist request, supervisor decision and audit (implemented)
  • 2 → 12: Authorized simulator submissions and queueing (implemented)
  • 12 → 9: Create one real order under verified submitter (implemented)
  • 12 → 10: Issued invoice and manifest source references (implemented)
  • 7 → 12: Leased processing, bounded retry and recovery (implemented)
  • 12 → 8: Idempotent local partner snapshot and receipt (implemented)
  • 2 → 13: Role and record permissions (implemented)
  • 13 → 3: Persist records and append history (implemented)
  • 2 → 14: Role and record permissions (implemented)
  • 14 → 3: Persist records and append history (implemented)
  • 2 → 15: Role and record permissions (implemented)
  • 15 → 3: Persist records and append history (implemented)
  • 13 → 15: Verified driver directory metadata and permission-scoped route links (implemented)
  • 2 → 16: Current role and assigned-route permissions (implemented)
  • 16 → 3: Atomic progress, evidence and shipment state (implemented)
  • 15 → 16: Immutable ordered stops and assignment (implemented)
  • 16 → 17: Shared simulation clock, delay and completion (implemented)
  • 2 → 17: Scoped samples, policy and alert review (implemented)
  • 17 → 3: Durable episodes, alerts and review history (implemented)
  • 17 → 13: Private driver conversations with scoped route links (implemented)
  • 2 → 18: Administrator permission and explicit UTC range (implemented)
  • 18 → 3: One read-only repeatable-read snapshot (implemented)

SYSTEMS DESIGN & OWNERSHIP

Engineering below the surface.

From a company workflow to a platform

The original El Sembrador role spanned service boundaries, operational interfaces, cloud topology, AWS/GCP synchronization, Kubernetes delivery and local virtualized compute. Atlas is the current inspectable demonstration of that breadth. Its Go/React/PostgreSQL implementation is identified separately from the historical stack.

A transaction is a business boundary

Approval validates the actor and proposal version, changes the product, records the audit event and inserts the outbox message atomically. A stale proposal cannot silently replace newer facts. Delivery can retry after the database commit without pretending that one HTTP request makes distributed changes exactly once.

Identity belongs at the API boundary

The browser uses authorization-code flow with PKCE in configured environments. API middleware validates tokens and roles before operational mutations. Navigation and hidden buttons are usability controls; server-side authorization decides whether an action is allowed.

One model across operational journeys

Orders, inventory, warehouse steps, shipments, dispatch and driver progress share record identities. This makes the handoff between functions visible, including where changes require a durable commit, where a worker handles delivery, and where a browser only presents synthetic state.

A demonstration with deliberate boundaries

The embedded static preview exposes synthetic architecture, staff, catalog and dispatch experiences. It ships no identity credentials, live API configuration or production data. API-backed approvals and transactions require the separately deployed services and are not executed by this portfolio.

Try route playback and document editing

The browser demo includes five fictional Florida delivery routes with moving vehicles, playback controls, selectable stops and a delivery timeline. The local document studio edits invoices, purchase orders and manifests with line items, live totals, browser-saved drafts, JSON export and printing. Sample documents do not issue invoices or change backend records.

INSPECT THE WORK

The system, made visible.

Open the interactive demonstration ↗

EXPLORE THE ARCHITECTURE

Components. Contracts. Consequences.

Modern synthetic demonstration of a connected operations ecosystem. Browser, API, identity and application data have explicit trust boundaries. Logical downstream receiving transactions share application PostgreSQL; modules are not separate deployed services.

Static explorer

Make the ecosystem and its trust boundaries inspectable.

Implementation

A single validated component graph drives 2D and optional spatial views, phase filters, component details and workflow links. The React interface loads operational views on demand.

Security & failure behavior

Every shipped asset is public. Client controls do not authorize API operations. The static architecture remains inspectable without the backend; protected workspaces require a verified API identity.

Tradeoff

One canonical model prevents diagrams from drifting apart. Spatial depth explains boundaries rather than measuring network distance.

REST API

Coordinate business workflows through a Go HTTP API.

Implementation

Typed contracts connect the browser to catalog approvals, orders, warehouse, documents and dispatch. Authorization combines token roles with record ownership or current driver assignment.

Security & failure behavior

Signed access tokens bind issuer/subject to allowlisted roles; each operation also enforces record scope. Missing or rejected identity cannot authorize protected operations. Partial OIDC configuration fails startup.

Tradeoff

A modular API keeps transactions and permissions close to business rules without creating a service for every domain noun.

PostgreSQL

Retain business state, revisions, evidence and delivery progress.

Implementation

PostgreSQL stores approved products, orders, stock, documents, routes and append-only history. Constraints, row locks and transactions preserve related facts together.

Security & failure behavior

Database grants restrict runtime writes; audit/history protections do not constrain database owners. Transactions roll back together; readiness distinguishes a reachable process from unavailable persistence.

Tradeoff

One application database simplifies consistent transactions and recovery. Database owners remain outside runtime audit restrictions.

Authentik

Delegate user authentication to a dedicated identity provider.

Implementation

An upstream Authentik public client uses authorization code with S256 PKCE. The browser confirms its identity and roles through the API before exposing protected workflows.

Security & failure behavior

Public authorization-code client uses S256 PKCE. The Go API validates signed access tokens, audience and dedicated role scope. Rejected or expired tokens do not create an authorized application session; unconfigured mutations remain disabled.

Tradeoff

Delegated identity avoids application password storage; availability and configuration of the identity provider remain operational dependencies.

Approval module

Publish product changes through independent review.

Implementation

Proposals retain their base product revision. Approval locks the current product and proposal, checks authorship and version, and commits the product, decision, audit and outbox event atomically.

Security & failure behavior

Creator self-approval is forbidden, including for administrators. API roles and actor identity govern decisions. Stale product versions conflict. Product, decision, audit and outbox changes commit or roll back together.

Tradeoff

Explicit conflicts prevent lost updates. Independent review adds a workflow step in exchange for attributable changes.

Transactional outbox

Keep approved changes and their integration events consistent.

Implementation

A versioned product-approved event is inserted in the same transaction as the product change. Stable event identities and expiring leases support deferred delivery.

Security & failure behavior

Stable event IDs, lease tokens and canonical payload validation constrain repeated delivery. Expired leases permit recovery; bounded retries and durable receipts preserve a single receiving effect across retries.

Tradeoff

At-least-once delivery requires duplicate-safe receiving. It does not promise exactly-once transport.

Integration worker

Process persisted integration work outside request handling.

Implementation

A separate Go process claims events, validates payloads, commits receiving effects and acknowledges delivery. Bounded timeouts, retry classification and structured logs expose failures.

Security & failure behavior

The worker claims persisted events with expiring fenced leases and validates before receiving. Database timeouts are bounded before lease expiry; lost acknowledgments can be retried against durable receiver receipts.

Tradeoff

Polling and database leases fit the bounded deployment; they trade immediate push delivery for a simpler recoverable worker.

Demo integration

Demonstrate integration receiving and durable acknowledgments.

Implementation

A synthetic catalog subscriber and fictional partner tables apply incoming events in separate receiving transactions, retaining receipts and record references.

Security & failure behavior

Receiver identity and payload/version checks operate inside a local synthetic receiving transaction. Duplicate events return durable receipts; conflicting payloads or versions are rejected rather than silently replaced.

Tradeoff

The receiving schema shares application PostgreSQL. It demonstrates transaction semantics, not an independent network failure domain.

Orders & warehouse

Connect orders to stock reservations, pick/pack and shipments.

Implementation

Orders snapshot approved prices and revisions. Whole-order reservations lock stock consistently, while operation IDs and optimistic versions fence repeated or stale commands.

Security & failure behavior

API roles and issuer/subject ownership govern order and warehouse operations. Stock is locked consistently. Insufficient stock, competing reservations, stale versions and repeated commands have explicit persisted outcomes.

Tradeoff

Integer cents and indivisible units make arithmetic explicit. Partial picking, split shipments, returns and backorders remain outside this version.

Documents & PDFs

Turn persisted business records into revisioned documents.

Implementation

Drafts autosave against a revision number. Issued invoices and manifests retain source records, totals, hashes and their generated PDF bytes.

Security & failure behavior

Ownership independently protects editing, issuing and downloading documents. Issued snapshots preserve source references. Revision conflicts retain the losing local text. Issued PDF bytes and business snapshots remain tied to their source revision.

Tradeoff

Compare-and-swap conflicts preserve edits without pretending to provide conflict-free simultaneous collaboration.

Replenishment

Review supply requests with clear ownership and authority.

Implementation

Requests capture product/vendor snapshots and quantities. A separate supervisor approves or rejects a versioned request with attributable history.

Security & failure behavior

Requester and independent supervisor have separate responsibilities; self-approval is forbidden. Stale or duplicate decisions are checked. An approved request records intent and does not itself change stock.

Tradeoff

Approval records intent; stock receipt and external purchasing remain separate operations.

Synthetic exchange

Connect fictional partner messages to real persisted workflows.

Implementation

Versioned JSON envelopes map incoming requests to orders and queue outgoing catalog, shipment and issued-invoice snapshots. UUIDs, payload hashes and receipts protect retries.

Security & failure behavior

Exact synthetic JSON v1 envelopes, stable UUIDs and canonical payload hashes validate exchange messages. Fenced claims, bounded retry, durable receipts and rejected-message retention make failures inspectable.

Tradeoff

The custom protocol is intentionally bounded and uses a same-database simulator; it is not an EDI compliance claim.

Profiles & operational threads

Keep operational conversations connected to business context.

Implementation

Membership-scoped threads reference authorized records. Messages and deduplicated local MIME previews commit together while preserving source language.

Security & failure behavior

Thread membership limits visibility even for administrators; linked records undergo separate current-role checks. Polling handles the bounded workflow. Protected identifiers are redacted when current record access is absent.

Tradeoff

Polling is sufficient for the bounded demonstration. The local message sink does not send external email.

Timekeeping & supervision

Connect employee identity, time records and reviewed corrections.

Implementation

Raw punches remain intact while supervisor decisions update effective time. Staff views combine weekly hours, private captures, leave and clearly labeled gross-pay estimates.

Security & failure behavior

Verified employee scope, private image permissions and independent supervisor review govern staff records. Corrections use versions and overlap checks while retaining raw punches; estimates expose missing or open time entries.

Tradeoff

Stored UTC instants retain IANA display zones. Synthetic captures and location signals do not prove physical presence or biometric identity.

Routing & dispatch

Turn persisted shipments into executable delivery plans.

Implementation

Dijkstra computes paths through a versioned graph; a deadline-first insertion heuristic schedules stops, service time and return windows. Dispatch atomically links shipments to registered drivers.

Security & failure behavior

Dispatcher permissions and registered driver assignments guard persisted route creation and dispatch. Unreachable paths and time-window failures are explicit. A heuristic failure does not establish global infeasibility.

Tradeoff

A bounded heuristic is explainable and deterministic, but does not guarantee a globally optimal route.

Driver operations

Record ordered delivery progress under current assignment.

Implementation

Route versions serialize driver updates. Delivery status and shipment state commit together, while normalized image evidence retains hashes and append-only associations.

Security & failure behavior

Current driver role and issuer/subject assignment authorize mutations and photo reads. Ordered progress uses route versions; delivery and shipment state commit together. Repeated evidence associations remain attributable.

Tradeoff

The demonstration establishes software behavior using synthetic evidence; it does not establish physical delivery.

Simulated monitoring & alerts

Translate fresh route observations into actionable exceptions.

Implementation

A controlled clock and increasing observations define off-route episodes. One persisted alert per episode separates acknowledgment from actual resolution.

Security & failure behavior

Current roles and assignments scope operational alerts and manager actions. Only fresh increasing observations extend an episode; persisted alert identity prevents duplicate alerts after retry or restart.

Tradeoff

The planned-path corridor is an explicit approximation; the demonstration does not imply a connected GPS fleet.

Persisted analytics

Explain operations through traceable, consistent measures.

Implementation

Read-only reporting uses one repeatable-read snapshot, explicit UTC cohorts and stated denominators. Decimal-string totals retain monetary precision and link back to source records.

Security & failure behavior

Administrator-only reporting reads persisted records under a repeatable-read, read-only database transaction. Unavailable data stays unavailable; zero denominators show no sample rather than fabricated metrics.

Tradeoff

Current inventory snapshots are not historical balances. Order totals are not recognized revenue or evidence of production scale.

Open full 2D architecture →

ENGINEERING SCOPE

Clear boundaries.

Original private implementation summarized from its intentionally public, sanitized frontend architecture model. No private source or business data is published.

  • The embedded demo uses synthetic local data. Live API operations and account sign-in are unavailable in this static preview.
  • The current Atlas implementation demonstrates the architecture; its code and screens are not presented as the historical El Sembrador production stack.
  • Historical employer records, infrastructure details and private source are not published. No production scale or load-test result is claimed.