Why Patient Data Liquidity Projects Stall on Security—and How OpenlyX Gets Unstuck

You have the mandate. The budget. Even a vendor lined up. But six months later, your patient data liquidity project is still in a PowerPoint. Sound familiar? The industry is littered with pilots that never reached manufacturing.

Security isn't the only reason—but it is the one that stops the show. Regulators, lawyers, and CISOs all have veto power. And right now, most architectures don't give them a reason to say yes. This article names the specific bottlenecks and shows how OpenlyX sidesteps them without cutting corners.

Who Needs Patient Data Liquidity and What Goes Wrong Without It

A field lead says teams that document the failure mode before retesting cut repeat errors roughly in half.

Siloed EHRs Are Costing You More Than You Think

Walk into any mid-sized hospital stack and you'll see the same scene: three different EHR flavors, none talking to the other. Clinicians log into separate portals just to check a solo patient's medication history. That's not a workflow hiccup—it's a clinical risk. I've watched a nurse waste twenty minutes hunting for discharge notes that existed, quietly, in a stack two floors away. The patient waited. The bed stayed occupied. The cost absorbed by nobody and everybody. That sounds like an operations problem, but peel back the layer: every delayed discharge, every duplicate lab order, every 'we'll treat primary and ask later' moment traces back to data that should have been liquid but was frozen. The trade-off is brutal—either you invest in plumbing now or you hemorrhage efficiency later.

'Everyone talks about interoperability standards, but nobody talks about the day-after—when you actually have to move data under assembly pressure.'

— A patient safety officer, acute care hospital

Payers Needing Real-window Claims Data

What ties these three scenarios together is not technical incompetence—it's the false belief that security posture and data flow are mutually exclusive. They aren't. But until you admit that your current state is bleeding outcomes, speed, and money, you won't have the stomach to fix the pipe.

Prerequisites: What You Must Settle Before Touching Code

Legal agreements and a shared data-use ontology

Most groups skip this: they wire up an API, run a trial with synthetic data, nod at each other, and call it done. The initial real patient query hits, and suddenly the lawyers are circling. You cannot bolt governance onto a moving pipe — it has to be locked down before the primary JSON payload moves. That means a signed data-use agreement (DUA) that specifies exactly which fields can flow, under what purpose codes, and for how long. I have seen projects stall for eight months because two health systems disagreed on whether de-identified lab results could be cached locally. Eight months. The fix is boring but fast: settle a shared ontology upfront. Define what 'consented use' means in machine-readable terms — FHIR Consent resources or a simple code list — and get all endpoints to agree on that vocabulary. Without it, your pipeline is just a permissionless hose that nobody trusts.

The catch is that legal groups hate abstract ontologies. They want natural language. You demand a document that says both 'the data subject agreed to Research Use Code XYZ' and spells out what that code allows in plain English. We fixed this by printing the agreed ontology as a one-page table, signed by every party, then encoding those same codes into the audit trail. Do not move past this phase until the DUA references the ontology by version number. Wrong order — you'll rebuild your entire ingestion layer.

Identity-proofing for all endpoints

Patient data liquidity assumes you know exactly who is sending data and who is receiving it. That assumption is naive. In practice, a research consortium once routed de-identified records through a staging server that had been configured with a generic admin credential — one that three former employees still knew. The seam blew out when a developer accidentally pointed assembly queries at that staging box. No breach, but a month of forensic auditing. The prerequisite here is not just OAuth or mTLS; it's proving that every endpoint — every database, every gateway, every client app — has a unique, revocable identity that is verified by a third-party authority (an OIDC issuer or a mutual TLS certificate authority).

What usually breaks initial is the compact clinic's EHR. It has no modern identity layer. You can't install a client certificate on a 2012-era practice management setup. That forces a trade-off: proxy the connection through a lightweight gateway (we use a tight container that does certificate rotation) or block that endpoint until they upgrade. 'But we'll lose data,' someone always moans. True — losing a day of clean flows beats losing your compliance license. Do not accept an endpoint that cannot prove its own name. Not yet. Not ever.

Minimum viable audit schema

Every pipe leaks eventually. When it does, you demand to know who looked at what, when, and under which consent. Not nice-to-have — regulatory requirement in most jurisdictions. I've seen projects that built beautiful data lakes but logged nothing about the query itself. When the auditor asked 'who accessed patient 447's oncology notes last Tuesday?', they had to reconstruct from network logs. That hurts. The prerequisite: agree on a minimum audit schema before code starts. Four fields: timestamp, requesting endpoint ID, resource type accessed, and consent code used. That's it. You can evolve later.

“Audit logs built after the pipe is running are always incomplete — you miss the initial six months of activity.”

— OpenlyX engineering lead, reflecting on a 14-month remediation project

Vary how you store this: one centralized log for consortia, individual per-endpoint for small clinics. But the schema must be identical across every node. Different date formats or ambiguous endpoint IDs will break your ability to trace a leak. We use ISO 8601 timestamps and UUID4 endpoint references — simple, unforgiving, portable. trial it with a fake incident. Run a mock query, then try to trace it from log alone. If it takes more than five minutes, your audit schema is too vague or your tools don't support it. Fix that before you move to the workflow section ahead.

The OpenlyX Workflow: From Onboarding to Production Data Flow

An experienced operator says the trade-off is speed now versus rework later — most shops lose on rework.

Phase 1: Register endpoints and define data contracts

You begin by pointing OpenlyX at each source—an EHR API, a research database, maybe a flat-file drop zone. The stack doesn't guess; it asks you to declare a data contract: what fields, what format, what freshness threshold. I have seen groups treat this as bureaucratic overhead. It's not. A contract that says 'patient_id is a UUID v4, updated daily by 03:00 UTC' prevents the silent drift that kills liquidity later. The catch? You must also register the consumer endpoint—where the data needs to land. Most groups skip this: they define the source, assume the destination will sort itself out. Wrong order. OpenlyX forces both registrations up front, and the handshake fails unless both sides can actually talk. That saves you a week of debugging after deployment.

Stage 2: Configure attribute-based access policies

Now you map who gets what—not by user ID, but by attributes: role, department, consent scope, data sensitivity level. A clinician in oncology sees full oncology records; a billing clerk sees only encounter dates and payer codes. This is where projects stall. 'We'll just use RBAC,' someone says—and three months later you're rebuilding. Attribute-based policies are harder to design but dramatically easier to audit. We fixed this by starting with a one-off rule: 'Deny all, then allow by attribute.' That hurts at primary—your DevOps person can't see anything. But it forces explicit trust boundaries. One rhetorical question worth asking your team: If a researcher accesses a patient row they shouldn't, does your current policy produce a log entry that would hold up in court? If the answer is no, you're not ready for production liquidity.

Step 3: Establish encrypted tunnels with lineage hooks

With contracts and policies set, OpenlyX spins up encrypted tunnels—mTLS or WireGuard, depending on your ops preference. But the real magic is lineage hooks: every row that moves gets a provenance stamp. Source stack, timestamp, transformation applied, destination. That sounds fine until you realize most ETL pipelines bury this metadata in logs nobody reads. OpenlyX bakes it into the data itself. The trade-off is storage bloat—maybe 15% more disk per payload—but the debugging ROI is absurd. What usually breaks initial is the tunnel handshake when a certificate expires at 2 AM on a Sunday. OpenlyX won't silently fail; it stops the pipe and fires an alert. A fragment worth remembering: no data flows through a stale credential. Ever.

“We traced a corrupted lab result back to a misconfigured attribute policy in under twenty minutes. Before OpenlyX, that workup would have taken three people a week.”

— CISO, mid-size hospital network, after initial month of production flow

Step 4: Monitor and rotate credentials automatically

Last step is where most liquidity projects rot. Human operators set up the tunnel, probe it, declare success—and six months later a credential rotates manually or, worse, doesn't rotate at all. OpenlyX assumes zero trust in human memory. It enforces credential rotation on a configurable cycle—30 days for API keys, 90 for service accounts—and the rotation hooks directly into your vault (HashiCorp, AWS Secrets Manager, or plain encrypted files). The pitfall? groups that skip automating the vault writeback. If your ops person has to edit a YAML file every rotation, you'll eventually get a lockout. I've watched this happen in three separate pilots. The fix is brutal but simple: OpenlyX refuses to accept a manually entered credential after the initial bootstrap. Automate it or watch the pipe stay dry. Your next step after configuring rotation is to hit the 'Validate Live Flow' button—it runs a mock payload through the entire pipeline and reports back within two minutes. Do it weekly.

Tooling Realities: What OpenlyX Assumes About Your Environment

Cloud-native vs. on-premise deployment options

OpenlyX runs well in Kubernetes clusters—that's where it breathes easiest. But I have seen groups assume they demand full cloud lift before they can start, and that's a myth. You can deploy on bare metal with Docker Compose for a solo-hospital pilot; the core data-plane logic doesn't demand a managed Kubernetes service. What breaks primary is the assumption that your network can tolerate a 50-megabyte FHIR bundle jumping across an on-premise firewall without buffer tuning. The trade-off is real: cloud gives you auto-scaling for query spikes, but on-prem avoids the compliance overhead of a data-sovereignty review board.

Worth flagging—OpenlyX doesn't require a specific cloud provider. We have it running on Azure AKS, Amazon EKS, and even a vanilla Rancher cluster inside a German hospital's DMZ. The painful part is never the deployment YAML. It's the egress cost when your IdP logs are shipped to a SIEM that sits behind a NAT gateway with throttled bandwidth. That stalls projects. Not the code.

'We spent three months negotiating which cloud region could host the query cache. OpenlyX was ready in two weeks.'

— Infrastructure lead, 400-bed research hospital

Integration with existing IdP and logging stacks

OpenlyX assumes you already have an identity provider that supports OAuth 2.0 client credentials or OIDC hybrid flow. If you're still on LDAP with no SSO layer, you'll demand a small IdP proxy—we've done this with Keycloak in about two days. The catch is that OpenlyX's token introspection expects a JWKS endpoint reachable within 200ms. Higher latency on token validation creates a backlog that looks like a data pipe leak when it's actually just an authentication bottleneck.

Most teams skip this: logging. OpenlyX emits structured JSON logs to stdout—nothing fancy, no bundled Elasticsearch. If your ops team routes logs to a Syslog server that truncates lines at 8KB, you lose the trace IDs needed to debug a dropped query. The fix is a four-line logstash filter, but I've watched three startups stall for a week because they assumed 'it just works.' Wrong order. Your logging pipeline maturity dictates how fast you can diagnose why a production FHIR bundle arrived with a corrupted tag.

A rhetorical question worth sitting with: is your monitoring stack ready to alert on latency variance rather than just uptime? Because OpenlyX's real-time query layer fails gracefully by returning partial results—but a 15-second pause in the auth check looks identical to a network partition on most Grafana dashboards.

Bandwidth and latency constraints for real-time queries

OpenlyX assumes your source systems can sustain at least 10 Mbps of stable throughput for the discovery phase. That sounds trivial until you're talking to a legacy EHR backend that still marshals XML over a VPN tunnel with 40ms jitter. What usually breaks initial is the attribute-level query throttling: OpenlyX fires concurrent requests to stitch patient identity fragments. If your network drops more than 0.5% of packets, the cache layer retries—exponentially—and you hit timeout windows in seconds, not minutes.

The actual fix is boring: a packet-loss budget test during onboarding. We provide a small script that sends 100 synthetic FHIR DiagnosticReport requests and measures tail latency. If p99 exceeds 900ms, you demand either a WAN accelerator or you must switch to batch-mode polling instead of real-time subscription. That's not a compromise—it's honesty about your local copper. Don't blame the tooling for physics you can't sweet-talk.

Variations for Small Clinics, Large Systems, and Research Consortia

According to published workflow guidance, skipping the calibration log is the pitfall that shows up on audit day.

Lightweight setup for clinics with limited IT staff

Small clinics usually have one part-time IT person—if they're lucky. Their EHR might run on a single server in a closet. OpenlyX's agent installs as a containerized sidecar, not a whole platform; you can drop it onto a refurbished Intel NUC or a modest cloud VM. The onboarding wizard asks only three things: source setup type, network egress rule, and a contact email for cert renewal alerts. I have seen a two-physician practice in Colorado move from zero data sharing to a live audit feed within an afternoon. The catch is hardware redundancy—you get none. If that NUC dies, the pipeline stops until someone plugs in a replacement. For a solo practice, that risk is acceptable. For a ten-clinic group, it isn't.

What usually breaks initial is certificate management. Small shops forget to rotate TLS keys, then the pipe goes silent. OpenlyX sends a 14-day warning to the operational contact; if ignored, it degrades to a caching mode so no historical data is lost. That's the trade-off—you trade some real-time readiness for zero manual babysitting. Worth flagging: smaller setups also cannot run the full anomaly-detection module. You get basic row counts and schema checks instead. The rest of the security envelope—encryption at rest, signed payloads, RBAC—stays identical to the enterprise build. Compliance posture does not shrink. Only the throughput does.

High-throughput configurations for hospital networks

Large academic medical centers produce data like a firehose—thousands of HL7v2 messages per second during peak OR hours. OpenlyX scales by sharding the ingestion layer across multiple nodes behind a load balancer. We fixed a throughput ceiling problem at a 900-bed system by switching from sequential to parallel bundle processing: the pipe went from 300 messages/second to 2,400 without touching the source EHR. The painful part is network segmentation. Most enterprise networks route data through three firewalls and an IDS before it reaches OpenlyX. Each hop adds latency and, occasionally, packet loss. You must negotiate a dedicated VLAN or a DMZ path, or the entire pipeline stutters.

Another pitfall: deduplication at high volume is memory-intensive. If your data includes lab results, radiology reports, and medication orders from different source systems, the same patient might appear in three identical feeds. OpenlyX uses a bloom-filter cache for primary-pass dedup, then a full-key reconcile in PostgreSQL. That works until the cache fills—typically after 48 hours at peak load—then the pipeline slows by roughly 15%. The fix is simple: schedule a nightly cache flush during low traffic. Most teams skip this until the seam blows out. Don't.

Federated governance for multi-site research

Research consortia pose an entirely different problem: nobody owns all the data. Each site wants control over what leaves its firewall. OpenlyX solves this with a federated governance layer—each site runs its own agent, sets its own consent filters, and signs its own data bundles. An orchestrator node at the coordinating center sees only the metadata index, not the raw rows. I've used this pattern across five sites studying rare pediatric cancers; each site approved exactly three fields (diagnosis code, age range, outcome) and blocked everything else. The system enforced that without any central admin seeing the denial logs. Privacy, not trust—that's the architecture.

'Federated query is not a feature you bolt on later. It is the architecture you choose when you admit you cannot control the edges.'

— Lead architect, multi-site oncology consortium, 2024

The real friction is consent drift. One site updates its IRB policy mid-study; their OpenlyX agent flags a field that was previously approved but now isn't. The orchestrator logs a schema mismatch and blocks queries touching that field until the study PI reauthorizes. That hurts because it can stall a data pipeline for weeks. Your mitigation: set up a PHR (project health review) alert that pings the consortium chair the moment a mismatch appears. Do not wait for the monthly call. The technology works—the governance calendar is what slips. Plan for quarterly consent audits, and insist each site runs a dry-run revocation test before the pilot ends.

Pitfalls: What to Check When the Pipe Leaks or Stops

Expired certificates and stale tokens

The flow dies silently. One morning the ETL pipe reports zero records pushed—no alarms, no red lights in the dashboard. You dig. The X.509 certificate your sidecar uses to talk to the FHIR server expired at 02:34 UTC. OpenlyX logs the handshake failure, but most default log levels bury it under 'INFO: connection refused, retrying.' You'll burn half a day hunting phantom network issues. The fix is boring: a cron job that checks cert expiry weekly and, if under 14 days, fires a PagerDuty alert. We learned this the hard way after a research consortium lost three days of oncology data because nobody watched the calendar. Token refresh logic is equally fragile—OAuth2 flows that break when the authorization server returns a 202 instead of a 200. OpenlyX assumes a clean handshake; when the seam blows out, check the token endpoint response code initial, not your network config.

Misaligned attribute mappings between systems

Two hospitals, same HL7v2 message format, different interpretation of 'patient class'. One sends 'I' for inpatient, the other sends 'INPATIENT'. OpenlyX maps on receipt, but the target system rejects the batch—silently. That sounds fine until you audit the data lake three weeks later and discover 12 % of admitted patients are missing. The pitfall is assuming the sender's dictionary matches the receiver's. What usually breaks initial is the 'gender' field: 'M' vs 'Male' vs '1' vs 'MALE'. The fix involves a mapping table that's reviewed at onboarding and re-validated every quarter. I have seen teams skip this step, push 50 000 records, then spend a sprint unpicking a tangled sex/gender mismatch that would have been caught in a two-hour alignment session. Worth flagging: OpenlyX's schema registry can flag unmapped fields during dry-run mode. Use it. Don't trust the data to be clean until you've seen a hundred records side-by-side.

Audit trail gaps that fail compliance review

Your pipe moves data perfectly. Then the compliance officer asks: 'Who accessed Patient 412's record on Tuesday at 14:07?' Your OpenlyX audit log shows the connector service account—generic, unhelpful. That hurts. The regulator wants the individual operator ID, the reason code, and the retention duration—and wants it queryable within seconds, not hours. The gap is that most data-liquidity tooling logs the technical handoff, not the business intent. OpenlyX can tag each transaction with a context envelope—user token, project ID, consent scope—but only if you wire it in before go-live. Retroactively adding audit hooks to a running pipeline is surgical, invasive, and expensive. Make the envelope mandatory from day one. One anecdote: a small clinic we worked with failed a surprise HIPAA audit because their FHIR server logs rotated every 24 hours; the liquidity pipe's metadata had already been garbage-collected. Compliance wanted retention ≥ 90 days. They rebuilt the logging layer from scratch. Don't be that clinic.

'Data in motion leaves a trail of breadcrumbs. The question is whether those crumbs are readable three audits from now.'

— compliance lead, regional health information exchange

Check three things before you trust your audit trail: are timestamps in UTC with millisecond precision, can you correlate a single data element back to the original API call, and does the log survive a full system restart without truncation? If the answer to any is no, you have a leak—one that might not show up for six months but will surface during the worst possible review. Fix it now, not then.

FAQ: Quick Answers to the Objections That Kill Projects

What if a partner refuses to share logs?

Then you have what I call a 'trust gap,' not a technical problem. Most projects stall because one hospital system simply won't hand over its audit trail—fear of exposing breaches, fear of lawsuits, fear of looking sloppy. OpenlyX doesn't force anyone to dump raw logs into a shared bucket. Instead, each partner runs their own local agent that generates cryptographic attestations—proof that data was accessed, transformed, and moved, without revealing the actual contents. The other side sees a signed receipt, not the messy internals. That sounds fine until a compliance officer demands full transparency during an audit. The fix: OpenlyX's attestation chain is verifiable by a third party, so you can prove integrity without exposing operations. Still, one CISO told me, 'I can't sign off unless I see every field.' We fixed that by letting them inspect redacted samples on their own VM, never leaving their network. The trade-off is speed—those attestations add a few milliseconds per transaction—but the alternative is no data flow at all.

How do we handle patient opt-out requests?

This is the question that kills projects during legal review—and it's the one most engineers ignore until the eleventh hour. OpenlyX treats opt-out as a first-class constraint, not a checkbox. When a patient revokes consent, the system propagates that signal to every node in the data pipeline within the same business day. No batching, no delayed sync that could leak a record. The tricky bit: what about data already in flight? OpenlyX tags every record with a consent token that expires on revocation, and downstream consumers must check the token before processing. If they don't, the pipeline stops cold. That hurts—researchers lose access to longitudinal datasets instantly—but it's the only pattern that survives an OCR audit. One clinic tried to override this for an ongoing study; we told them they'd need a new IRB waiver first. They grumbled, but they didn't get sued. Worth flagging: OpenlyX does not delete historical audit logs of opt-out events—it preserves the chain for legal defense. That's a pitfall if you assumed 'opt-out means everything vanishes.' It doesn't. It stops new use, but the record of the decision stays.

Is OpenlyX HIPAA-compliant out of the box?

No—and anyone who promises that is selling snake oil. Compliance isn't a checkbox you install; it's a process you run. What OpenlyX does ship is a hardened configuration that satisfies the most common audit patterns: encryption at rest and in transit (AES-256, TLS 1.3), automatic logging of all data access events, and role-based access controls that map to your org chart. But you still need to sign a BAA with each downstream partner. You still need to configure retention policies. You still need to validate that your environment doesn't leave keys on disk—I've seen teams blow six months because they stored decryption secrets in environment variables. Most teams skip this: OpenlyX provides a compliance validation script that runs against your staging cluster before you touch production data. It flags missing BAAs, weak cipher suites, and audit log gaps. The script is opinionated—it will fail if you've set 'log_retention_days' to zero—and that's intentional. The catch: passing the script doesn't mean you're compliant. It means you've eliminated the obvious holes. Real HIPAA compliance requires a third-party risk assessment and a documented security management process. OpenlyX shrinks the gap, but it doesn't close it for you.

'When a partner asked us to sign a BAA during a pilot, I assumed that was just paperwork. Then I read the indemnification clause. We almost killed the whole project.'

— Security architect at a 200-bed hospital, recounting a near-miss that OpenlyX's pre-flight checklist caught

One more objection that comes up repeatedly: 'Can we use OpenlyX across state lines with different privacy laws?' Short answer: yes, but you must configure jurisdiction-aware routing. OpenlyX lets you assign geographic tags to each node, so data from California stays inside California unless you deliberately bridge regions. That means you might need multiple deployment instances—one per regulatory zone—which adds operational overhead but keeps you on the right side of CCPA, GDPR, and similar standards. The mistake I see most often: teams assume one pipeline fits all regions. It doesn't. You'll either block data that should flow, or leak data that shouldn't. Neither is acceptable when the next objection is the one that kills the project outright. Your next step: run a 30-day validation pilot with a single partner, a single consent type, and a single region. Prove the opt-out path works. Prove the attestation chain holds. Then extend.

In published workflow reviews, teams that log the baseline before optimizing report roughly half the repeat errors; the trade-off is an extra twenty minutes upfront versus a multi-day cleanup loop nobody scheduled.

Your Next Step: Run a 30-Day Validation Pilot

Pick one use case with existing data agreements

Most teams skip this step—they grab a shiny new dataset nobody has permission to share. That kills the project before code even compiles. Instead, choose a single clinical use case where data-sharing agreements already exist. Maybe it's a cross-site research cohort that's been approved for years but never actually moved data. Or a quality reporting pipeline that still runs on weekly CSV exports via encrypted USB sticks—painful but legal. The goal isn't technical brilliance yet; it's proving you can move a byte from point A to point B without anyone getting fired. I've watched a seven-hospital consortium try to start with oncology genomics—three months of legal paralysis. Waste. Start with something boring but clean: lab results for a post-op readmission study. Agreements signed. IRB cover in place. Then you test the seam.

The catch is that 'one use case' will feel painfully small. That's the point. A 30-day pilot isn't the full system; it's a controlled detonation. Prove the pipe holds before filling it.

Deploy OpenlyX edge node with test data

Here's where your environment assumptions hit concrete. OpenlyX's edge node runs in your existing infrastructure—your VPN, your authentication, your outbound-only firewall rules. No inbound ports. That's the security gate. We deploy it first with synthetic test data that mimics your real schema but contains nothing protected. A fake patient table: MRN 000001, name 'Test Alice,' date shifted. Run the node against your staging environment. What usually breaks first is network routing—your security team will flag traffic that looks like it's phoning home, even though it's just a heartbeat check on an allowlisted endpoint. Worth flagging: this is the moment you'll discover whether your security operations center really supports data liquidity or just talks about it. Two or three tickets get kicked back. Normal. Work through them.

The pilot's real deliverable: a signed-off network diagram showing exactly where data transforms, encrypts, and exits. Not a promise. A diagram.

Prove security gates before scaling

Wrong order kills projects. Teams often prove throughput first—how fast can we stream?—then discover the security posture leaks like a sieve. Flip that. In weeks two and three of the pilot, stress the gates, not the pipes. Run penetration tests against the edge node. Simulate a compromised internal user trying to exfiltrate extra records. OpenlyX's built-in access controls should stop that; if your IDP misconfigures group mappings, the seam blows out. Fix it now, not after you've onboarded five sites. A concrete example I've seen: one group skipped this, scaled to twelve clinics, and then discovered their row-level filter wasn't applying to historical data retro-imports. That's a one-week rollback and a lot of angry compliance emails.

“We spent ninety percent of our validation budget on security; the actual data flow took three days. That saved us from a breach during the first real query.”

— Security architect, midwestern health system, after a pilot that nearly failed on week two

That sounds extreme until you realize one misconfigured edge node can expose every patient record across a research network. By the end of week four, you don't need a perfect production system. You need a signed record showing: data moved, data stayed encrypted, access logs held up to audit. Then you scale. One clinic. One dataset. One validated pipe. Repeat. That's the 30-day pilot—it's not a demo. It's the first brick.