Senior/Principal AI Infrastructure Team

Denizen Blu Compute Marketplace, Reach & Beacon Start: Immediately Production Completion Deadline: September 14, 2026 This deadline is non-negotiable. Overview Parinita is building the Denizen Blu Compute Supply Marketplace, a production-grade global system that allows individuals, enterprises, hosting companies, data centers and other infrastructure owners to make unused CPU, GPU and accelerator capacity available to Denizen Blu. We already have the architecture and an existing codebase. We need a very senior engineering team capable of taking the existing implementation through final integration, hardening, testing and production deployment by September 14, 2026. This is not: a prototype a proof of concept a demo a UI-only marketplace an architecture consulting engagement a six-week discovery project The required output is working production code deployed and passing acceptance tests by September 14, 2026. If you cannot immediately allocate senior engineers and work against this deadline, please do not apply. What We Are Building The Denizen Blu marketplace creates a global supply network for AI compute. The operating flow is: Provider joins → connects CPU/GPU/NPU hardware → Parinita Reach enrolls and attests the machine → hardware is benchmarked and qualified → provider offers available compute → Parinita bids for capacity → provider accepts → capacity becomes available to Denizen Blu → BluRoute determines workload placement → Beacon resolves the appropriate L7 runtime endpoint → workload executes inside the Denizen Compute Runtime → usage is securely metered → provider sees earnings in real time → usage settles weekly → provider generates/accepts settlement → Ramp handles AP/payment → accounting flows downstream The supplier sells compute capacity to Denizen Blu, not directly to Denizen Blu customers. Existing Architecture The architecture has intentionally separated responsibilities. Denizen Blu Compute Marketplace Owns: Provider onboarding Hardware/node registration Compute inventory Supply offers Provider asking prices Parinita bids Bid acceptance Capacity contracts Provider dashboard Parinita buyer/admin console Real-time earnings display Weekly settlement presentation Provider invoice/payment workflow Provider reputation and operational history Parinita Reach Reach is our endpoint identity, trust and remote-operation layer. Reach owns: Endpoint enrollment Machine/workload identity Hardware attestation lifecycle Heartbeats Health Service publication Typed remote operations Revocation Quarantine Fleet lifecycle Agent rollout Marketplace node-state integration Reach does not own global workload placement. Reach must not introduce a separate VPN or competing network architecture. Provider machines initiate connectivity outward. Parinita Beacon Beacon is our deterministic Layer-7 service/workload destination-selection system. Beacon owns: Candidate endpoint construction Tenant hard filtering Service matching Sovereignty/compliance eligibility Health eligibility Deterministic scoring Stable tie-breaking Versioned topology Decision evidence L7 publication intent Beacon must return an explicit failure if there is no compliant endpoint. Beacon does not own global compute placement. BluRoute BluRoute is already the placement brain for Denizen Blu. BluRoute decides: Which provider Which region Which capacity pool Which silicon Which compute class Which runtime Which qualified infrastructure Do not create another scheduler. The marketplace provides additional qualified supply to BluRoute. Private Transport Reach consumes a provider-neutral Private Transport layer. The underlying transport implementation must remain abstracted and replaceable. Do not expose underlying infrastructure vendors in the marketplace architecture. Do not build another VPN product. Denizen Compute Runtime The marketplace requires a secure runtime deployed onto supplier hardware. It must: Receive authorized Denizen Blu workloads Isolate workloads from the host Allocate CPU/GPU/NPU resources Enforce RAM limits Enforce storage limits Enforce network policy Report health Meter actual resource use Produce authoritative usage telemetry Securely destroy temporary workload state Support signed upgrades Support rollback Drain safely Recover following interrupted updates Neither side should be able to compromise the other. The provider must not have access to Denizen customer workloads. Denizen workloads must not have arbitrary access to the provider's machine. BluSettle BluSettle is the authoritative Denizen Blu usage and cost-attribution layer. Every dollar owed to a provider must trace to: BluRoute Job → Provider → Capacity Contract → Node → Resource → Usage interval → Contract rate → Amount earned → Weekly settlement → Payment Duplicate usage and duplicate settlement must be impossible. Weekly Provider Payments Providers are paid weekly. Required workflow: Weekly close → reconcile authoritative usage → calculate settlement → display amount to provider → provider generates/accepts invoice → Ramp payable created → Parinita approval → payment → payment status returned to marketplace → accounting synchronization downstream Ramp is the AP/payment layer. QuickBooks is downstream accounting and is not the usage or marketplace ledger. Bare-Metal Compute Some marketplace hardware may arrive with no operating system. We therefore need a production bare-metal provisioning path: Hardware claim → ownership authorization → bootstrap → signed Parinita image → boot → Reach enrollment → hardware attestation → qualification → Denizen marketplace activation Initial requirements include ARM64/RK3588-class distributed edge systems and multi-node chassis. Hardware-specific provisioning must use adapters. Do not hard-code the platform around one hardware vendor. Current Codebase An existing source package already includes substantial implementation for: Marketplace backend Provider APIs Provider dashboard Parinita buyer/admin console Reach Beacon Database schema Alembic migrations Usage receipts Weekly settlements Ramp integration boundary BluRoute integration boundary Private Transport abstraction Bare-metal provisioning boundary Kubernetes deployment artifacts Docker deployment OpenAPI specifications Security documentation Runbooks Acceptance gates Automated tests You will receive the existing source immediately after engagement. The expectation is to review quickly, preserve good existing implementation, fix what is required, complete the missing production integrations and deploy. Do not spend several days redesigning the product. Required Work 1. Marketplace Complete and production-harden: Provider onboarding Provider identity Node lifecycle Supply offers Bid/counter-bid workflow Capacity contracts Provider dashboard Earnings calculations Buyer/admin console Weekly settlements Invoice lifecycle Audit logs OIDC RBAC Rate limiting Idempotency HA Transactional outbox Metrics/logs/traces Production deployment 2. Reach Complete: Enrollment One-time enrollment credentials Workload/device identity Attestation verification Signed agent communications Replay protection Heartbeats Health Service registry Typed operation broker Revocation Quarantine Agent update mechanism Canary deployment Rollback Fleet operations A provider must not be able to self-certify its hardware. Unattested or quarantined machines must not receive workloads. 3. Beacon Complete: Versioned topology Candidate generation Hard eligibility filters Deterministic scoring Stable tie-breaking Health/capacity signals Route evidence Publication adapter ACK/NACK behavior Explicit no-compliant-endpoint handling Failure recovery Rollback Performance testing Hard constraints must execute before optimization. 4. BluRoute Integration Bind the marketplace to the actual Denizen Blu interfaces for: BluIndex BluRegistry BluRoute BluSettle Capacity availability Provider status Provider certification Runtime dispatch Usage Cost attribution Marketplace capacity must appear as qualified Denizen Blu supply. BluRoute remains the sole global placement authority. 5. Provider Compute Runtime Complete/harden: Linux runtime Container isolation CPU allocation GPU allocation NPU support where applicable Memory quotas Ephemeral storage Network controls Job lifecycle Health reporting Usage telemetry Secure workload cleanup Node drain Signed upgrades Recovery Crash handling 6. Billing & Ramp Complete: Signed authoritative usage Contract-rate enforcement Usage reconciliation Weekly close Settlement adjustment Provider acceptance Ramp vendor mapping Payable creation Approval state Payment webhook handling Payment failure handling Idempotency Downstream accounting synchronization 7. Bare-Metal Provisioning Complete framework for: Hardware claim Ownership validation Node/chassis discovery Bootstrap Image manifest Signature verification ARM64 image installation BSP adapters A/B image updates Rollback Recovery Reach enrollment following boot Production Deadline September 14, 2026 This means deployed, tested and operational, not "code complete." We expect the selected team to begin immediately and operate on a compressed production sprint. Indicative execution: September 7–8 Codebase takeover, environment deployment, interface validation, blockers eliminated. September 9–10 Reach, Beacon, Marketplace and BluRoute integration paths operational. September 11 Compute Runtime, Private Transport integration and node lifecycle operational. September 12 Usage, BluSettle, weekly settlement and Ramp workflow operational. September 13 Failure testing, security testing, load testing, rollback, observability and acceptance remediation. September 14 Final production acceptance, documentation, runbooks, deployment handoff and GO LIVE. Workstreams should run in parallel. This is not intended to be a sequential one-engineer project. Acceptance Test The project is not complete until we can demonstrate: Provider creates account. Provider connects hardware. Reach enrolls endpoint. Identity is established. Attestation passes. Hardware is inventoried. Hardware is benchmarked. Provider publishes capacity and ask. Parinita places a bid. Provider accepts. Capacity contract is established. Capacity enters Denizen Blu capacity systems. BluRoute selects marketplace capacity. Beacon resolves the correct compliant runtime endpoint. Authorized workload reaches the machine. Workload executes in an isolated runtime. Host/workload isolation is verified. Usage is recorded correctly. Usage is attributable to BluRoute job and contract. Provider earnings update. Weekly settlement closes. Provider generates/accepts settlement invoice. Ramp payable is created exactly once. Payment state returns to the provider dashboard. Quarantined/revoked hardware receives no new jobs. Cross-tenant access fails. Failed integrations recover correctly. Restarts do not lose contracts, usage or settlement state. Dashboards/alerts are operational. Runbooks are tested. Deployment can be reproduced from source. Production acceptance is signed off. Required Engineering Level We are looking for senior, staff, principal-level engineers or a genuinely senior small team. We are not looking for: Junior developers Generic full-stack teams WordPress/web agencies Low-code developers Teams learning distributed systems during this engagement Agencies whose senior architect sells the engagement and junior engineers perform the work Because of the September 14 deadline, we expect multiple senior engineers working in parallel. Ideal experience: Distributed systems AI inference infrastructure GPU clouds Compute marketplaces Kubernetes Linux Go Python/FastAPI PostgreSQL gRPC Envoy Gateway API Cilium Containers/containerd mTLS SPIFFE/SPIRE PKI Ed25519 Device/workload identity Hardware attestation NVIDIA CUDA AMD ROCm ARM64 Bare-metal provisioning NATS/Kafka-class messaging Prometheus OpenTelemetry Grafana GitOps Software supply-chain security Ramp APIs/webhooks Payment/accounting integrations How to Apply Begin your response with: SEPTEMBER 14 — DENIZEN COMPUTE Then answer every question below. Can you commit to production completion by September 14, 2026? How many senior engineers can you allocate immediately? Who will personally write the production code? What is the most similar production infrastructure system you have built? What specifically did you personally implement? Explain how you would safely execute AI workloads on third-party GPU machines. How would you isolate the provider's host environment from the Denizen workload? Explain the difference between BluRoute-style global placement and Beacon-style L7 endpoint selection. How would you prevent a malicious provider from fabricating GPU utilization? How would you guarantee economically exactly-once settlement over technically at-least-once event delivery? Describe your Kubernetes, Cilium/Envoy, mTLS and workload-identity experience. Describe your GPU runtime experience. Have you built bare-metal provisioning systems? Have you integrated Ramp, QuickBooks or comparable payment/AP systems? What do you see as the three highest technical risks to completing this by September 14? Provide a proposed staffing plan for September 7–14. Provide relevant GitHub repositories, architecture samples or production references. Generic proposals will be rejected. Engagement Structure Immediate start. Milestone and acceptance-test driven. Daily engineering progress and blocker review. Source must be committed continuously. No large "final delivery" dump on September 14. All production changes require tests. All P0 failures must be resolved before acceptance. September 14, 2026 is the production completion and go-live deadline.