Blockchain and AI Technical Expert

Parinita is assembling a focused senior launch team across distributed storage, backend systems, RAG/AI, identity and policy, platform/SRE, and production validation. We will hire the right combination of specialists and multi-discipline engineers. A Staff/Principal technical lead is one role in the team, not the entire hiring plan. The four-day objective is a controlled production launch of a tightly defined surface. We will reduce optional scope before weakening tenant isolation, durability, authorization, evidence, recoverability or RAG grounding. Detailed Recruiting Brief v3 | September 2026 | Page PARINITA AI EDGE | ENCLAVE + ALMANAC ENGINEERING LAUNCH TEAM The mission Take Parinita Enclave and Parinita Almanac through a tightly controlled four-day launch sprint and establish a production-grade path that is technically defensible. The four-day objective is a controlled production launch of a defined surface, not an artificial claim that every roadmap feature has reached GA. We will cut optional scope before weakening tenant isolation, durability, authorization, evidence, recoverability, or RAG grounding. By the end of the sprint, the team must be able to show what is: LIVE / ACCEPTED — exercised against real dependencies and cleared for the controlled launch surface. INTEGRATION-GATED — implemented but still waiting on a real service, environment, test, benchmark, or acceptance condition. ROADMAP / DESIGNED — intentionally not represented as production functionality. What we are building Parinita Enclave — Object Trust Runtime Enclave is not intended to reinvent disk-level distributed storage. Ceph/RADOS/RGW is the Tier-0 durable object-storage substrate. Parinita's differentiation sits above it. Stratum is the governed object transaction and trust layer. It owns the logical object lifecycle, tenant scope, object/version identity, policy envelope, Object Trust Contract, Object Passport, retention/legal-hold extensions, trust inheritance, capability leases, evidence state, and the point at which an object becomes visible as committed Enclave state. Flash is the object-intelligence layer. It enriches objects with AI-driven classification and analysis while failing safely if AI dependencies are unavailable. Witness establishes identity, authority, delegation, and scoped capability. Secure evaluates whether the proposed action is permitted in the current context. Chrysalis provides the evidence/finality integration for consequential state transitions. The intended high-assurance object flow is conceptually: Client → Enclave API / Stratum → Witness → Secure → Ceph durable object → Chrysalis evidence → Stratum COMMITTED/VISIBLE If evidence or policy requirements are not satisfied, the object must not be prematurely represented as a successful high-assurance Enclave commit. The implementation must use explicit durable states and recovery semantics rather than pretending Ceph and Chrysalis share a single distributed ACID transaction. Parinita Almanac — Sovereign, Verifiable RAG Almanac is first and foremost a production RAG platform. It is not being repositioned away from RAG. The core path is: Authorized Enclave source → extract → chunk → classify → embed → hybrid retrieve → rerank → assemble grounded context → approved model generation → claim/evidence validation → answer + provenance/evidence The 10/10 Almanac features strengthen that RAG pipeline: Knowledge Passport — lineage for a retrieved entry/chunk back to the exact source object/version and transformation state. Knowledge Release — a versioned corpus/index release so a consultation can identify the exact knowledge state used. Consultation Contract — principal, purpose, corpus scope, policy, jurisdiction, model/use constraints, freshness and evidence requirements for a RAG request. ProofRAG — material claims are mapped to authorized source evidence; insufficiently supported claims must be flagged or withheld rather than disguised by decorative citations. Answer Passport — query fingerprint, knowledge release, retrieved evidence, ranking/reranking context, model/version, output hash, claim/evidence map, and evidence references. Trust inheritance — applicable Enclave restrictions follow the source into chunks and derived RAG artifacts. Contradiction handling — conflicting authoritative sources are surfaced rather than silently resolved by similarity score alone. Knowledge recall / replay foundations — identify downstream RAG artifacts affected by a corrected or revoked source and reconstruct historical consultation state where evidence exists. The product relationship is simple: Enclave governs the source object and what it is allowed to become. Almanac retrieves the right authorized evidence and produces traceable RAG answers from it. Target production architecture Layer Primary technology / service Responsibility Durable object substrate Ceph / RADOS / RGW S3-compatible object storage, versions, replication/EC, scrub/recovery, Object Lock where applicable Enclave transaction plane Stratum services + PostgreSQL Governed object state, tenant/version identity, trust contract, passport, leases, evidence state, visibility Object intelligence Flash Classification, sensitivity/secret signals, content intelligence, anomaly/ransomware signals, enrichment Identity / authority Witness + OIDC/JWT/JWKS Principal identity, delegation, scoped authority, short-lived capabilities Runtime policy Secure Contextual allow/deny and policy decision for protected actions Evidence Chrysalis Consequential-event submission, finality state, verification reference RAG metadata / retrieval PostgreSQL + pgvector or approved equivalent Corpora, entries, embeddings, full-text/vector indexes, retrieval state Almanac RAG Almanac / Tracker services Ingest, chunk, embed, hybrid retrieval, rerank, context, grounded generation, ProofRAG Model execution Denizen Blu / approved model endpoint Embeddings, reranking and/or generation as configured and accepted Deployment Kubernetes + Helm or approved target Scheduling, rollout, secrets integration, network controls, scaling, health Observability Prometheus/OpenTelemetry-compatible stack or approved equivalent Metrics, traces, logs, SLO evidence, alerting The exact production dependency endpoints and credentials must be supplied and validated in the deployment environment. The team must not substitute local mocks and then label the result “production.” Open roles We expect to engage multiple people. Senior, Staff and Principal-level candidates are welcome across the roles below. Strong engineers can own more than one workstream, but nobody is expected to be expert in every layer. 1. Technical Launch Lead / Staff-Principal Distributed Systems Engineer Mission Own the end-to-end launch architecture and force clarity at every boundary between storage, object state, identity, policy, evidence, RAG and operations. Responsibilities Audit the current Enclave and Almanac repositories, deployment manifests, database migrations, tests and runbooks. Convert ambiguous cross-service behavior into explicit contracts, state machines and failure semantics. Define the launch surface and decide what is accepted, gated or removed from scope. Own the object state progression across Stratum, Ceph and Chrysalis without false atomicity claims. Own service-to-service dependency contracts between Enclave, Almanac, Witness, Secure, Chrysalis and model endpoints. Review authorization boundaries and make sure backend/internal calls cannot silently bypass the external trust model. Establish idempotency, retry, timeout, circuit-breaker and reconciliation rules for cross-system operations. Drive architecture decisions quickly; reject unnecessary rewrites that endanger the four-day target. Coordinate technical owners, unblock dependencies, run daily go/no-go checkpoints and maintain the acceptance matrix. Lead the final launch review and issue a clear GO / CONDITIONAL GO / NO-GO with evidence. Day-4 deliverables Approved architecture and dependency contract map. Cross-product state/failure model. Closed list of critical blockers for the launch surface. Reproducible deployment path and acceptance report. Explicit inventory of live vs integration-gated vs roadmap capabilities. Must have Production distributed-systems experience across multiple stateful services. Strong PostgreSQL/data-consistency background. Experience designing idempotent workflows and recovery after partial failure. Ability to read Python quickly; Go or Rust experience is highly valuable. Experience making production launch decisions under real time constraints. 2. Ceph / RGW Storage Platform Engineer Mission Make Tier-0 storage boring, recoverable and measurable, so Parinita engineering can concentrate on the trust and AI layers above it. Responsibilities Deploy or validate the target Ceph cluster and RGW topology. Configure buckets/pools, versioning, replication or erasure coding, placement rules and Object Lock/retention capabilities where required. Validate S3 behavior required by Enclave, including multipart, range requests, metadata, version IDs and error semantics. Define and test the no-bypass topology: protected Enclave namespaces must not be exposed to users/services in a way that allows them to write around Stratum policy. Validate capacity, headroom, recovery behavior, scrub/deep-scrub, rebalance behavior and expected failure domains. Exercise disk/OSD/node failure and recovery rather than relying on documentation. Establish metrics/alerts for cluster health, degraded PGs, recovery pressure, capacity thresholds and RGW errors/latency. Document operational procedures for expansion, replacement, recovery and maintenance. Work with the backend engineer to align Ceph object/version semantics with Enclave logical transaction state. Day-4 deliverables Working target RGW endpoint with documented storage classes/pools. S3 contract validation for the launch surface. No-bypass storage/network design and test evidence. At least one tested storage failure/recovery scenario. Ceph health/alert dashboard requirements and operator runbook. Must have Hands-on production Ceph/RADOS/RGW administration. Real experience with OSD failure, PG recovery, EC/replication, scrub and cluster performance. S3 semantics beyond simple PUT/GET demos. Understanding of WORM/Object Lock and retention behavior. Strong plus Large NVMe Ceph clusters, multisite RGW, Kubernetes/Rook-Ceph, performance tuning, backup appliances or regulated storage environments. 3. Backend / Enclave Object Trust Engineer Mission Make Stratum the enforceable object trust boundary above Ceph. Responsibilities Implement/harden Stratum object APIs and durable state transitions. Ensure object/version identity is stable and cryptographically bound to the stored content and metadata required by policy. Implement Object Trust Contracts and Object Passports as real persisted, versioned data structures. Implement short-lived Object Capability Leases scoped to principal, object/version, action, purpose, expiry and relevant restrictions. Enforce retention/legal-hold behavior without depending only on application convention. Implement evidence-gated visibility using explicit states such as PREPARED/PENDING/DURABLE/ATTESTED/COMMITTED/FAILED/QUARANTINED as appropriate. Ensure retries cannot double-commit, lose evidence links or surface an object prematurely. Build reconciliation workers for partial success: e.g., Ceph write succeeded but Chrysalis or metadata transition failed. Implement trust inheritance hooks for downstream Almanac ingestion and derived artifacts. Eliminate unsafe development fallbacks from production paths. Write negative and concurrency tests around state transitions. Day-4 deliverables Tested governed PUT/GET/version flow over the real Ceph/RGW dependency. Persisted Object Trust Contract + Object Passport lifecycle. Evidence-gated commit/recovery behavior. Capability-lease enforcement for at least the controlled launch surface. Negative tests proving direct invalid transitions are rejected. Must have Strong backend engineering in Python, Go, Rust, Java or equivalent. PostgreSQL transactions, locking, migrations, concurrency and idempotency. Durable workflow/state-machine design. Secure API design and tenant isolation. Strong plus S3 integrations, cryptographic metadata, policy engines, audit/evidence systems, distributed transaction patterns, event/outbox architectures. 4. RAG / Retrieval / AI Engineer — Almanac Mission Ship a production RAG path that is retrieval-first, evidence-aware and precise about what it knows. Responsibilities Harden source ingestion from authorized Enclave objects. Implement reliable extraction for the accepted launch document types and record parser/version metadata. Design chunking appropriate to source type and preserve exact source coordinates needed for citations. Build and validate embedding generation, version pinning and index compatibility. Operate PostgreSQL/pgvector or the accepted retrieval backend with tenant/corpus isolation. Implement hybrid retrieval (vector + lexical/filtering), candidate generation, reranking and deterministic evidence packaging. Create/version Knowledge Passports and Knowledge Releases. Implement Consultation Contracts that constrain corpus, purpose, principal, policy, model, freshness and evidence requirements. Harden prompt-injection/content-poisoning handling so retrieved document text is treated as untrusted evidence, not executable instruction. Implement ProofRAG at the claim/evidence level, not merely by checking whether the LLM emitted [1] or [E3] tokens. Require abstention/insufficient-evidence behavior when material claims are unsupported. Surface contradictory source evidence where confidence/authority cannot safely resolve it. Generate Answer Passports linking the answer to source versions, retrieval state, model/version, claim/evidence map and evidence references. Build evaluation cases for retrieval quality, citation precision, answer grounding, contradiction handling and negative authorization. Day-4 deliverables Working Enclave-source-to-RAG-answer flow against real dependencies. Versioned source/chunk/embedding/retrieval lineage for the launch corpus. Hybrid retrieval + reranking evaluation report. Claim-level citation/grounding tests with abstention cases. Answer Passport for every accepted controlled-launch RAG answer. Must have Production RAG experience beyond prompt demos. Embeddings, vector search, lexical retrieval and rerankers. pgvector, Elasticsearch/OpenSearch, Vespa, Qdrant, Milvus or equivalent hands-on experience. Document ingestion/extraction and chunking trade-offs. RAG evaluation: recall/precision, ranking quality, citation quality, answer grounding and failure analysis. Strong plus Enterprise/regulated RAG, provenance, temporal/versioned retrieval, multimodal retrieval, knowledge graphs, secure RAG, red-team testing for prompt injection. 5. Security / Identity / Policy Engineer Mission Ensure every protected action has a real identity, scoped authority and deny-by-default policy path. Responsibilities Integrate/validate OIDC/JWT/JWKS authentication in production mode. Integrate Witness authority/delegation decisions for customer, agent and service principals. Integrate Secure runtime policy checks for protected operations. Define service identities and least-privilege permissions across Enclave, Almanac, Ceph/RGW, PostgreSQL, Chrysalis and model endpoints. Remove development tenant-header/default-token behavior from the production path. Design capability-lease verification and anti-replay/expiry behavior. Validate secrets handling and KMS/HSM integration contracts; do not embed long-lived secrets in images/config maps. Establish mTLS/service-authentication requirements where appropriate. Lock down network egress/ingress so “sovereign” does not mean a NetworkPolicy that still permits unrestricted outbound traffic. Build negative tests for cross-tenant access, privilege escalation, invalid delegation, expired capability, bad issuer/audience, policy-denied operations and internal-service bypass. Review audit logs to ensure sensitive payloads/secrets are not leaked. Day-4 deliverables Production auth path exercised with the real identity endpoint or explicitly gated if unavailable. Witness/Secure decision matrix for launch operations. Service-to-service identity map and secrets plan. Negative-security test results. Network/egress policy appropriate to the launch environment. Must have OIDC/OAuth2/JWT/JWKS and service identity. RBAC/ABAC/capability/delegation patterns. API and microservice threat modeling. Secrets/key management; KMS/HSM integration patterns. Network segmentation and deny-by-default controls. 6. Platform / SRE / Kubernetes Engineer Mission Turn the code into a repeatable, observable, recoverable production service. Responsibilities Harden Docker images and Helm/Kubernetes manifests or the approved deployment target. Implement production configuration validation and fail-closed startup for required dependencies. Manage PostgreSQL/pgvector deployment assumptions, migrations and upgrade/rollback safety. Configure readiness/liveness/startup probes that reflect real dependency state without causing restart storms. Define resource requests/limits, autoscaling, disruption budgets and rollout policy. Implement secrets integration and immutable image/version promotion. Establish CI/CD checks: lint, tests, dependency/security scan, migration check, image scan and deploy validation. Instrument metrics, traces and structured logs for Enclave and Almanac critical paths. Build dashboards/alerts for object state backlog, failed evidence submissions, Flash/AI queue health, ingestion failures, index freshness, RAG latency, retrieval quality signals and dependency health. Execute backup/restore for PostgreSQL state and document Ceph recovery dependencies. Exercise rollout, rollback and restore before customer exposure. Create a launch-day runbook and incident escalation path. Day-4 deliverables One-command or documented reproducible deployment from approved prerequisites. Immutable image/version manifest. Monitoring/alerting baseline. Exercised DB backup/restore and application rollback. Production runbook with dependency failure actions. Must have Kubernetes/Helm or equivalent production operations. Stateful workloads and PostgreSQL operations. CI/CD, containers, secret management and observability. Real incident/recovery experience. 7. QA / Performance / Resilience Engineer Mission Prove the launch surface by trying to break it. Responsibilities Build a cross-product acceptance matrix covering functionality, isolation, security, recovery, performance and evidence. Create deterministic integration fixtures for Enclave + Almanac. Test cross-tenant/cross-corpus denial paths. Exercise retries, duplicate requests, stale tokens, expired leases and partial dependency failures. Test service restart during object commit, evidence submission, ingestion and RAG consultation. Validate no object becomes visible before its required Enclave commit state. Validate no Almanac answer can retrieve from an unauthorized corpus. Validate ProofRAG behavior on supported claims, unsupported claims, conflicting sources and malicious prompt-injection content. Establish baseline throughput/latency for the launch surface and record the test method rather than publishing unmeasured SLA claims. Exercise Ceph failure/recovery with the storage engineer and DB restore/rollback with SRE. Produce a final release-evidence pack with test inputs, results, failures, residual risks and rerun instructions. Day-4 deliverables Release acceptance matrix with PASS/FAIL/GATED status. Functional + negative-security + tenant-isolation suite. Dependency-outage/restart/recovery evidence. Initial performance baseline with methodology. Final critical/high defect list and retest status. Must have Production integration/acceptance testing across distributed services. Negative security and tenant-isolation testing. Load/performance testing with reproducible methodology. Failure injection and recovery validation. 8. Optional: AI/RAG Evaluation & Red-Team Specialist We may also engage a dedicated evaluator if the RAG engineer should remain focused on implementation. Focus Build a gold evaluation set for retrieval and grounded answer quality. Measure retrieval recall, ranking quality, source attribution, unsupported-claim rate and abstention quality. Adversarially test indirect prompt injection, conflicting documents, stale/superseded content and poisoned sources. Review Answer Passports and claim/evidence maps for false confidence. Define regression gates for model, embedding, reranker and chunking changes. Day 0 — prerequisites before the four-day clock starts The sprint is only meaningful if the team has access to real dependencies. Before Day 1, Parinita and the selected team should confirm availability of: Current Enclave and Almanac repositories and issue/acceptance lists. Target deployment environment and sufficient cluster privileges. Ceph/RGW endpoint and administrative contact/credentials required for setup. PostgreSQL/pgvector or authority to deploy it. OIDC/JWKS issuer and test principals. Witness, Secure and Chrysalis integration endpoints or a written statement that a specific dependency remains gated. Approved model/embedding/reranking endpoints for Almanac. Required DNS/TLS/secrets/KMS/HSM integration details for the launch environment. A representative but safe test corpus and tenant matrix. Named Parinita decision-maker for rapid architecture/scope decisions. A missing external dependency does not justify a fake local substitute being called production. It becomes an explicit integration gate. Four-day execution plan Day 1 — Establish truth, deploy foundations, freeze contracts Morning Repository and deployment audit. Re-run existing tests and classify what they actually prove. Identify critical defects and stale/hallucinated assumptions. Freeze launch scope and assign workstream owners. Validate Ceph, DB, identity, policy, evidence and model endpoints. Afternoon Deploy/validate Ceph RGW + PostgreSQL/pgvector + application namespaces. Apply DB migrations and seed controlled test tenants. Establish service identities/secrets/network boundaries. Define Stratum object-state and Almanac consultation-state contracts. End-of-day exit criteria All required dependencies are either reachable and tested or explicitly GATED. Critical architecture decisions are closed. The team can deploy all in-scope services in the target environment. No one is still assuming a mock/local service is equivalent to the production dependency. Day 2 — Enclave governed object lifecycle Morning Prove governed PUT/GET/version/list flow through Stratum over Ceph. Persist object/version identity, hash, trust contract and passport. Validate tenant boundaries, retention/legal hold and no-bypass topology. Afternoon Integrate Witness/Secure on protected actions. Exercise Chrysalis submission/finality states for evidence-gated operations. Validate partial-failure reconciliation and idempotent retry. Validate Flash enrichment state and safe failure behavior. End-of-day exit criteria A controlled launch tenant can write/read a governed object. Direct policy bypass is demonstrably blocked for the protected namespace. Object state survives process restart and dependency failure. A failed evidence/AI dependency does not silently produce a false successful state. Day 3 — Almanac source-to-answer RAG lineage Morning Ingest authorized Enclave objects. Extract/chunk supported documents with exact source coordinates. Generate embeddings with pinned model/version and build a Knowledge Release. Validate tenant/corpus isolation and retrieval filters. Afternoon Exercise hybrid retrieval + reranking against a representative evaluation set. Apply Consultation Contracts before retrieval/generation. Generate grounded answers through the approved model endpoint. Enforce claim/evidence mapping and abstention. Produce Answer Passports tied to exact object versions and Knowledge Release. End-of-day exit criteria The team can trace an accepted answer from claim → retrieved passage → chunk → source object/version. Unauthorized corpus retrieval fails. Unsupported questions demonstrate safe insufficient-evidence behavior. Prompt-injection content is treated as untrusted evidence rather than higher-priority instruction. Day 4 — Break it, recover it, measure it, launch only what passes Morning Cross-tenant negative tests. Kill/restart critical services during object write and RAG consultation. Simulate identity/policy/evidence/model dependency outage. Exercise DB backup/restore and application rollback. Run controlled load/performance baseline. Afternoon Close critical/high launch blockers or remove affected surface from launch. Run final acceptance suite. Review security, data isolation, recovery and observability evidence. Publish live/gated/roadmap matrix. Issue GO / CONDITIONAL GO / NO-GO. Launch rule: no deadline overrides a failed trust, tenant-isolation, durability, authorization, evidence or grounded-RAG gate. Non-negotiable acceptance requirements Enclave Protected writes go through the governed Stratum path. Production tenant identity is not taken from a caller-controlled development header. Object Trust Contract and Object Passport are durable and tied to the exact object version. Required evidence state is distinguishable as submitted/finalized/failed; an arbitrary ID is not assumed to prove finality. Partial failure is recoverable and idempotent. Retention/legal hold behavior is negative-tested. Flash failure is visible and does not silently fabricate semantic output. Ceph degradation/recovery behavior is understood and observable. Almanac RAG Authorization and corpus scoping happen before retrieval. Exact source object/version lineage survives extraction, chunking and indexing. Embedding/rerank/generation model/version are recorded where needed for reproducibility/audit. Retrieval uses the accepted combination of vector, lexical and structured filtering appropriate to the launch corpus. Material claims have source evidence or are explicitly unsupported/abstained. Contradictory sources are not silently disguised as a single fact where the system lacks authority to resolve them. Answer Passport records the accepted consultation lineage. An LLM's own “evidence analysis” is never treated as independent proof that the answer is true. Platform / security No default secrets, dev auth, mock tenants or permissive production fallback. Egress/ingress rules are explicit and testable. Backups restore; rollbacks work. Dashboards/alerts expose queues, dependency failures and degraded states. The exact deployed image/build can be identified. Production claims are tied to acceptance evidence, not architecture diagrams. Engineering rules for this sprint 1. Do not rewrite Ceph. Use the mature storage substrate unless a specific launch-blocking defect proves otherwise. 2. Do not hide partial failure. Persist explicit state and reconcile it. 3. Do not call local mocks “production integrations.” Mark the dependency gated. 4. Do not make RAG look grounded by decorating answers with citations. Prove claim-to-source mapping for the accepted surface. 5. Do not let AI-generated analysis become the root of trust. Cryptographic evidence can prove what happened, not whether an LLM's reasoning was correct. 6. Do not publish unmeasured performance/SLA claims. Record methodology, then publish accepted measurements. 7. Do not bypass policy for internal services. Service-to-service authority is still authority. 8. Do not trade isolation, durability or recoverability for the four-day deadline. Reduce scope instead. What strong candidates look like You have personally operated systems where failure mattered. You can describe what broke, how you found it, what state was left behind, how you recovered it, and how you prevented recurrence. We value engineers who are comfortable saying “this is implemented but not yet production-accepted” rather than turning roadmap intent into claims. Strong candidates typically have several of the following: Stateful distributed systems under real load. Ceph/RADOS/RGW, object storage, S3 or storage control planes. PostgreSQL transactions/migrations/HA and pgvector or comparable retrieval systems. Production RAG with measurable retrieval and grounding evaluation. OIDC/JWT/JWKS, policy engines, capability/delegation systems. Kubernetes/Helm and production SRE. Evidence/provenance/audit pipelines. Cryptographic service integrations, KMS/HSM or signing systems. Multi-tenant security architecture. Incident response and disaster recovery. Current services are heavily Python-oriented. Strong Go or Rust experience is valuable, particularly for systems/performance work. Who should not apply This role is not a fit if your relevant experience is primarily: Building chatbot demos around managed APIs. Running local Docker Compose and calling it production. Writing architecture documents without owning deployment/failure behavior. Assuming Kubernetes automatically solves security/reliability. Treating a vector database as a complete RAG system. Recommending a new framework/database/storage engine before understanding the existing code. Avoiding operational responsibility after merge. Selection process We want a fast, high-signal process because the work is immediate. Step 1 — written response. Answer the role-specific questions below and include links or concise descriptions of relevant production work. Step 2 — technical discussion. 30–45 minutes focused on one real system you owned and one failure scenario relevant to your workstream. Step 3 — repo/architecture fit. Selected candidates review the launch brief/repository and identify the first changes they would make. We are evaluating judgment, not presentation theater. Step 4 — engagement and sprint start. Confirm scope, rate/commercial terms, availability, owner and Day-1 deliverables. Application questions Answer the general questions plus those relevant to your role. General 1. Which role(s) are you applying for? State Senior / Staff / Principal level if useful, but emphasize what you can personally own. 2. What can you commit to delivering in the next four days? 3. Describe one production system you personally built or operated that is directly relevant. What failed in production and what did you do? 4. What timezone are you in, what hours can you overlap, and when can you start? 5. Do you prefer hourly, daily or fixed-scope commercial terms? Provide your rate/proposal. 6. Are you applying individually or as part of a team? If a team, list each person, role and concrete deliverable. Storage / Ceph 7. Describe a real Ceph/RGW incident you handled: what failed, what did cluster state look like, how did you recover it, and what did you change afterward? 8. How would you prevent users and internal services from bypassing Stratum while still allowing Stratum/RGW to scale? 9. For a high-assurance bucket, how would you combine Ceph Object Lock/retention with an application-level governed state machine without creating contradictory sources of truth? Backend / distributed systems 10. Design an evidence-gated Enclave PUT where Ceph can succeed and Chrysalis can time out. What durable states, idempotency keys, retry rules and reconciliation jobs do you use? 11. How do you prevent a retry from producing two logical Enclave versions or exposing a PENDING object as COMMITTED? 12. What belongs in the Object Trust Contract vs the Object Passport vs operational metadata? RAG / retrieval / AI 13. How would you evaluate whether hybrid retrieval + reranking actually improved Almanac instead of merely changing scores? 14. How would you enforce claim-level evidence and abstention rather than checking that an answer contains citation markers? 15. How would you represent versioned corpus/index state so a historical Answer Passport can identify what was searchable at consultation time? 16. How would you handle two authoritative source documents that materially contradict each other? 17. Describe your defense against indirect prompt injection contained inside retrieved enterprise documents. Security / policy 18. How would you model authority for a human, an AI agent acting under delegation, and an internal service without giving any of them blanket storage credentials? 19. What claims must you validate in JWT/OIDC tokens and how do you handle key rotation, issuer/audience errors and clock skew? 20. What would you test to prove service-to-service policy cannot be bypassed through an alternate internal endpoint? Platform / SRE 21. What must pass before you permit production traffic to a new Enclave/Almanac release? 22. How would you deploy DB migrations safely with multiple application replicas and a required rollback path? 23. What are the first ten metrics/alerts you would require across Ceph, Stratum, Flash and Almanac? 24. Describe a backup/restore or disaster-recovery test you personally executed rather than merely documented. QA / resilience 25. List the first ten failure/negative tests you would run against Enclave + Almanac together. 26. How would you demonstrate that a tenant can never retrieve another tenant's object or RAG chunk, including through caches/indexes? 27. How would you build a repeatable performance baseline without turning a four-day benchmark into an unsupported SLA promise? What the team receives Selected candidates will receive the current code repositories, architecture/white-paper packet, build/operate material, hallucination/overclaim audit, acceptance requirements, and the credentials/environment information Parinita is able to provide for the launch sprint. You are expected to challenge contradictions in those materials. The code, the deployed environment and repeatable tests determine technical truth. Detailed Recruiting Brief v3 | September 2026 | Page PARINITA AI EDGE | ENCLAVE + ALMANAC ENGINEERING LAUNCH TEAM ENGAGEMENT • IMMEDIATE START Build the trusted data + RAG path with us. Four-day controlled-launch sprint first. Ongoing production engineering and operations work available for strong performers and teams. Apply for the workstream you can own. We are willing to hire multiple specialists rather than force one person to cover every domain. ENCLAVE Make object trust enforceable. ALMANAC Make RAG evidence precise. PRODUCTION Make failure recoverable. What to send in your first response The role(s) or workstream(s) you want to own. One directly relevant production system you personally built or operated, including a failure you handled. Your earliest start, timezone and realistic availability across the four-day sprint. Your hourly, daily or fixed-scope commercial proposal. Answers to the role-specific technical questions in this brief; if applying as a team, map each person to a concrete deliverable. If you can make storage boring, object trust enforceable, authorization fail closed, RAG evidence precise, and production failures recoverable, we want to hear from you.