Choosing a Witness Complex That Doesn't Lose Your Coarse Topology

Witness complexes promised a cure for the curse of dimensionality. Instead of building a simplicial complex on every point, you pick a few landmarks and then let the rest of the data witness which simplices to include. It sounds efficient. And it's — until your coarse topology vanishes.

The problem is that witness complexes are brittle. A bad choice of parameters — too few landmarks, too many neighbors, wrong metric — and the persistence diagram turns to noise. I've seen projects where analysts assumed the witness complex preserved the same topology as the full Čech complex, only to find holes disappearing and connected components merging incorrectly. This article is about not making that mistake. We'll go through the mechanics, the pitfalls, and the concrete choices that keep your large-scale structure intact.

Where Witness Complexes Actually Show Up in Real Work

TDA on sensor networks and point clouds with millions of points

You have a sensor net that streams 15 million readings overnight. Full Čech complex? Good luck—your workstation stutters by row 70,000. That’s where witness complexes creep into real code. People rarely reach for them inside a tidy paper example. The trigger is almost always size. I once watched a team hammer a persistent homology pipeline for 18 hours, only to crash on the sorting step. They switched to a witness construction the next morning. The topology came back in under forty minutes—but it came back wrong in three obvious places. Coarse topology matters exactly when you can’t afford to miss a single connected component or a big cycle that spans the whole cloud. In practice, witness complexes survive because they trade fine local detail for a workable global shape. The sensor case is brutal: holes appear where the network coverage actually has a gap, and the witness complex sometimes kills that hole because the landmark set skipped that region. That’s not a bug—it’s the premise. You accept that a 0.3% false-negative rate on loops beats an 100% failure to compute.

Landmark selection strategies: random, maxmin, and density-based

Choose the wrong landmark strategy and your coarse topology disappears before the first simplex is built. Random selection is fast—extremely fast—but it samples noise. A dense sensor cluster might crowd out landmarks from a sparse but critical bridge area. That bridge vanishes. Maxmin fixes this by picking points that are farthest from each other sequentially. It preserves the spread. The catch is computational cost: maxmin scales quadratically in the number of candidate landmarks, and a team once told me their maxmin selection took longer than the homology computation itself. Density-based selection tries to sample proportionally to local point density, which sounds right. It often over-represents high-density clutters and misses the coarse periphery. I have seen exactly one project where density-based outperformed maxmin for preserving coarse loops—the dataset had a uniform background with sparse outliers that defined the real topology. That’s the exception. Most teams revert to maxmin after a shorter test than they should run. Worth flagging: no selection strategy fixes a bad witness ratio. If you take only 200 landmarks from a 2-million-point cloud, the coarse topology will fragment no matter how clever the picker.

The trade-off is sharper than people admit. More landmarks means better topological recall but slower construction. Cut too far the other way and you lose the coarse structure you came to find. I advocate for running a quick persistence sweep on three or four landmark sizes before committing to final parameters. The extra hour saves days of debugging later.

Trade-off between computational speed and topological accuracy

Speed tempts everyone. Witness complexes are marketed as the fast path—and they're, until they aren’t. The construction themselves are indeed cheaper than alpha or Čech for massive point sets. But accuracy degrades in ways that surprise new users. A common pitfall: the witness complex preserves the zeroth homology (connected components) fairly well, but the first homology (loops) can vanish or appear spuriously. That hurts when your application hinges on detecting holes—say, coverage gaps in a sensor field or void regions in a material scan. I once debugged a pipeline where every loop above diameter 0.4 was missing because the witness radius covered too much. Reducing the radius brought back the loops—but constructed 5× more simplices. The speed advantage evaporated. So the real trade-off is not witness-versus-Čech in the abstract. It’s the operational question: what coarse features can you sacrifice without breaking your analysis? If your goal is detecting large-scale connectivity against background noise, witness complexes are the tool. If you need every medium-sized loop, you may need to stay with the full complex or accept a stricter witness radius that erodes the performance benefit. A former colleague called this the “20-centimeter problem”—fine details always cost more than you budget.

‘A witness complex gives you the horizon, not the mailbox in front of it. For the horizon, it’s excellent. For the mailbox, bring a spade.’

— systems architect after three failed evaluations on a street-level lidar dataset

Foundations Readers Confuse: Witness vs. Čech vs. Alpha

Definition of witness complex and its parameter k (number of nearest neighbors)

A witness complex starts with a point set called witnesses — usually your full data — and a smaller set of landmarks. The rule is simple: include a simplex of landmarks if its vertices are among the k nearest neighbors of some witness. That k parameter is not a dial you twiddle once. Pick k too small and the complex fragments into islands; too large and you reconstruct the entire Čech complex, defeating the purpose. I have debugged two teams that ran an entire pipeline with k = 5 and wondered why their homology vanished — they had fewer than five landmarks in the first place.

The catch is that k interacts with landmark selection density. Uniformly sampled landmarks? You can get away with a lower k. But if your data has clusters with sparse representation in landmark space, that same k will misalign loops and voids. One concrete fix: sweep k across three values — half the intrinsic dimension, the full dimension, and twice that — then check persistent homology stability before committing.

So the definition seems straightforward. The cost of getting it wrong is a phantom topology — or worse, a topology that looks real but collapses when you add two more witnesses.

How witness complexes differ from Čech and alpha complexes

Čech and alpha complexes build simplices based on geometric overlap of balls. Witness complexes build them based on proximity order — which points are nearest to which landmarks, never mind the exact distance. That sounds fine until you need a hole to appear at a specific scale. With Čech, you can say "radius 0.3 spawns this 1-cycle." With a witness complex, you say "for this landmark density and k, a cycle appears somewhere between scale 2 and 4." Worse, witness complexes can introduce spurious homology when landmarks cluster — something alpha complexes can't do unless you miscompute the Delaunay triangulation.

Čech complexes grow simplices combinatorially with the point count — O(2n in the worst case). Witness complexes scale with the number of landmarks and k. That's the trade-off: computational tractability for topological ambiguity. Alpha complexes sit in between, but only for low-dimensional Euclidean data. If your data lives in a manifold of dimension > 3, alpha becomes geometrically expensive. Witness complexes shrug — they only care about nearest-neighbor lists.

Honestly — most applied posts skip this.

The practical difference: Čech gives you a clean filtration parameter (radius). Witness gives you a rank parameter (k) that doesn't map linearly to any metric scale. That makes interpreting persistence diagrams harder. One team I consulted switched from witness to alpha halfway through a project because they could not explain to their stakeholders why a 1-cycle persisted for k = 7 through 11 but vanished at k = 12. With alpha, the story was "radius 0.4 to 0.6 — that's a real feature."

Common misconception that witness complexes always recover the same homology

'A witness complex with enough landmarks and large enough k is equivalent to the Čech complex on the landmark set.' — that's false for any finite sampling.

— Paraphrased from a frustrated analyst who spent three weeks debugging a shape descriptor

The myth: increase landmarks and k until the witness complex "converges" to the full topology. Convergence theorems exist — but they assume infinite sampling and exact metric recovery. Your data is not infinite. And even dense sampling can fail: a sparse landmark configuration near a small loop might never include all three vertices in any witness's k-nearest neighbors if the loop's points are far from any landmark.

We fixed this once by using the witnesses themselves as landmarks — a self-centered witness complex. That guaranteed every data point participated, but at the cost of larger complexes. Wrong order? Not yet. The deeper issue is that witness complexes preserve coarse topology — large loops, large voids — but consistently miss small features that Čech recovers trivially. If your application cares about millimeter-scale features in a meter-scale point cloud, witness complexes are the wrong tool. That's not a bug; it's the definition. The misconception is expecting a fast approximation to behave like an exact computation. I have seen teams burn two sprints chasing that phantom. Don't be that team.

Patterns That Usually Work for Preserving Coarse Topology

Using enough landmarks — the 10% rule rarely fails

Pick too few landmarks and your witness complex turns into a skeleton. I once watched a team run 50 landmarks on 10,000 points—of course the persistence diagram showed nothing but noise. Their loops vanished. The coarse structure? Gone. A rule that holds up across most real datasets: start with roughly 10% of your data as landmarks, and never go below 100. That sounds arbitrary until you hit a 90-point set where the landmark count ties the witness count — then you lose coverage on long edges entirely. The catch is scale: 10% of a million points is expensive, but you can subsample smartly. Use max-min seeding; it spreads landmarks across the coarse shape. Still, the 10% floor is a starting point, not a guarantee—sparse regions punish uniform sampling hard.

What if your data is high-dimensional? Then 10% may still be too sparse. Bump it to 15–20% and check whether the 0-dimensional persistence (connected components) stabilizes. That’s your first signal. If it jumps between landmark sets, you’re under-sampled.

Setting k large enough — but not too large

Small k gives you a sparse, ragged complex that tears easily. Large k packs in so many simplices the witness complex starts resembling the full Čech — defeating the purpose. I’ve seen practitioners set k = 3 on a 50-landmark set and wonder why the coarse hole never appears. It’s because three neighbors barely cover the local neighborhood. A decent heuristic: k = 2 × (dimension + 1) as a floor, then double it until the persistence landscape stabilizes. On a 3D point cloud that means k = 8 at minimum. But test increments: k = 12, 16, 20. The moment the bottleneck distance to the full complex stops dropping, stop increasing. That’s your sweet spot.

Wrong order. Pushing k too high first, then cutting landmarks — that creates dense pockets of simplices around a few landmarks while leaving gaps elsewhere. The coarse topology warps unevenly.

“The witness complex is a compromise — treat it like one. Over-parameterize in one direction and you lose the whole point of the approximation.”

— Anonymous computational topology engineer, after three failed projects

Validating against a full complex on a subset

Most teams skip this: compute the Čech or Alpha on a 10% random subset of your data, then compare persistence landscapes against your witness complex on the full dataset. The bottleneck distance should stay under 0.1 × (max persistence lifetime). If it blows past that, your landmarks or k are wrong. One concrete anecdote: we fixed a failing pipeline by running this validation on a 5,000-point subset — took 20 minutes. The witness complex had been missing a persistent 1-cycle because k was too small. After tuning, the bottleneck distance dropped from 0.45 to 0.08. That hurt. But it saved the analysis.

A shorter check: plot the persistence diagrams side by side. If the witness diagram has fewer points in the medium-to-large death range, you’re sacrificing coarse structure. That’s a red flag. Re-seed landmarks or increase k. One rhetorical question — why trust a witness complex you haven’t validated against a ground truth? You wouldn’t deploy a classifier without a test set. Same logic applies.

Anti-Patterns and Why Teams Revert to Full Complexes

Using too few landmarks — the collapse that nobody sees coming

Twenty landmarks for ten thousand points. I have watched three teams make this exact bet, usually because somebody ran out of RAM during prototyping and decided the witness complex was the culprit. The real culprit was the landmark count. With too few landmarks, the witness complex becomes a starved skeleton — it can't distinguish a cluster from a short edge. Coarse loops vanish. The two-holed torus you expected turns into a lump. The catch is that the persistence diagram still looks *plausible*: a few long bars, a few short ones, nothing screams "broken." But the topology you cared about — the coarse shape that motivated the whole analysis — has collapsed into noise. We fixed this once by stepping from 20 landmarks to 200 on a 15,000-point point cloud from LiDAR scans. The difference was not subtle; the first run showed one connected component where there should have been three. That hurts.

Field note: applied plans crack at handoff.

Default parameters are a trap — k = 2 or 3 rarely preserves coarse structure

Most software ships with k = 2 or k = 3 as default. That choice is fine for small synthetic examples — it fails fast on real data. A witness complex built with k = 2 ties each witness to only its two nearest landmarks. For a dense region, this might be enough. For sparse regions or areas with uneven sampling, k = 2 generates a connectivity graph that's essentially a nearest-neighbor graph in disguise — and we already know those lose large-scale topology without dense sampling. What usually breaks first is the first homology group: a cycle that should persist for thirty percent of the filtration dies after three steps because the witness simply can't "see" enough landmarks to complete the loop. Worth flagging—I have seen teams re-run the same analysis five times, tweaking everything except the k parameter, and then conclude that witness complexes don't work. The fix: start with k = 8 or k = 10, then tune downward. That alone stopped one team from reverting to a full Čech complex.

Uniform landmark sampling fails when data is clustered

Random uniform sampling of landmarks sounds clean and unbiased. It's not — not when your data lives in clusters separated by empty space. Uniform sampling pulls landmarks from everywhere, which means heavily populated clusters get *fewer* landmarks than they need while sparse regions get *too many*. The result: coarse topology inside each cluster collapses because the witness complex lacks enough landmarks to represent internal structure, while the space between clusters is over-resolved and generates spurious small bars. The anti-pattern here is especially seductive because the code runs fast and the output looks tidy. "We used uniform landmarks — standard practice." Standard practice for a uniform distribution, maybe. For real data — for the clustered, non-convex point clouds that actually need topological analysis — uniform sampling is a fast path to giving up and switching to an alpha complex. I have seen this reversal inside three months of a six-month project. The fix is cheap: use density-adaptive landmark selection (e.g., maxmin sampling or a simple k-means initialization) and watch the persistent homology stabilize.

The pattern is consistent across all three anti-patterns: the witness complex gets blamed, but the mistake lives in preprocessing. Landmark count too small, k too low, sampling strategy misaligned with density — these are not failures of witness theory. They're failures of configuration. And when a team reverts to a full complex, they rarely document *why*. The full complex works; the witness complex "didn't." The missing detail is that the witness complex was never set up for the data it was given. Next time you hear somebody say witness complexes lose topology, ask how many landmarks they used — and watch the silence.

“We tried witness. It collapsed everything to a point. So we switched to Čech and it worked. End of story.”

— From a Slack thread where the landmark count was 15 for a 12,000-point scan of a branching vascular structure. The coarse topology was a tree with four main branches. The witness complex saw one branch. Nobody checked the params.

Maintenance, Drift, or Long-Term Costs of a Witness Complex

The Hidden Tax of Rebuilding

A witness complex is never a build-once artifact. I have watched teams celebrate a fast initial construction only to discover three months later that their landmark set — chosen from a static sample — no longer reflects the data distribution. The data drifted. New clusters emerged. Old landmarks became orphans. That sounds fixable, but the rebuild cost surprises everyone. You can't simply re-run the same pipeline with updated landmarks; you must recompute the nearest-neighbor relations between every witness and every new landmark. For a dataset with 200,000 points and k = 30, that's six million distance queries. Per rebuild. Do it weekly and you're burning compute that nobody budgeted for.

What usually breaks first is the nearest-neighbor index. Most teams use a KD-tree or a vantage-point tree for the initial build, but those structures degrade as data streams in. The index must be rebuilt or dynamically updated — an operation that costs O(n log n) even with efficient libraries. One team I worked with tried incremental insertion into an R-tree. It worked for three months. Then the tree depth doubled, query time spiked, and their nightly pipeline started timing out at 4 A.M. They reverted to a full Čech complex because, paradoxically, brute-force neighbor searches became faster than maintaining the broken index.

The catch is memory overhead. Witness relationships are edges waiting to happen — each witness stores references to its nearest landmarks, and for large k (say, 50 or 100) the adjacency structure can exceed the original data size. I have seen a 12 GB point cloud balloon to 40 GB in witness-relation storage alone.

Streaming Data Kills Static Witnesses

Most blog posts assume a fixed dataset. Real pipelines ingest new points every hour. The witness complex offers no cheap update rule — there is no equivalent of inserting a vertex into a Delaunay triangulation. You add one new witness point; you must re-query its nearest landmarks and potentially flip existing simplex memberships if the new point changes the density neighborhood.

Wrong order. The landmark set itself becomes stale first. If landmarks are fixed but data grows, new witnesses may lie far from any landmark, producing long edges that collapse the coarse topology you were trying to preserve. I have debugged persistence diagrams where a single stream session introduced 300 new points that formed a separate void — invisible to the witness complex because no landmark sat near enough to capture it. The team spent two weeks adding adaptive landmark reselection, which effectively meant rebuilding from scratch every 500 insertions.

‘We thought we were saving time with witnesses. We ended up writing a scheduler that re-indexes every Tuesday at 2 A.M.’

— Senior engineer, logistics routing team, after six months of maintenance

That hurts. The promised speed advantage evaporates when you factor in the cron jobs, the failed runs, and the Monday-morning firefights over why the persistence diagram looks nothing like last week's.

Long-Term Drift You Can't Patch

Even if your data is static, usage patterns drift. The topological features you cared about in year one may shift as the team asks new questions. A witness complex tuned for a specific coarse scale — say, epsilon = 5.0 — encodes that scale into the landmark density. Ask for epsilon = 3.0 later, and the witness relationships may become too sparse to detect anything. You're not just rerunning a parameter; you're questioning the geometric structure of the entire witness graph. Most teams I talk to discover this when a new PhD student joins and tries to compare persistence diagrams across two epsilon values. The comparison is meaningless because the underlying witness scaffold differs.

Not every applied checklist earns its ink.

What do you do? You maintain two witness complexes side by side, doubling the storage and the update cost. Or you admit that the witness complex was a premature optimization and switch to an alpha complex — which has well-defined recomputation bounds and doesn't force you to choose landmarks at all. The long-term cost of a witness complex is not the computation; it's the rigidity. Every new question exposes a hidden assumption baked into the landmark selection. And assumptions, unlike code, are rarely documented.

When NOT to Use a Witness Complex

When coarse topology is critical — detecting holes in sensor coverage

Witness complexes trade accuracy for speed. That trade becomes a straight-up loss when you need the exact coarse shape. I've watched a team map sensor coverage in a warehouse — they wanted to know if the blind spots formed a loop. The witness complex said no holes. The Čech complex found a persistent H₁ class that matched the physical column obstructing the signal. The witness had collapsed that column's footprint because no landmark landed in the narrow gap between the sensor cone and the obstruction. Coarse topology isn't just about large-scale features. It's about features that stay alive across scales. If your hole lives at a single persistent threshold — say, 12-centimeter radius — and your landmarks sample at 10-centimeter intervals, you miss it. That hurts. The rule: if your application is detecting loops or voids in physical coverage, stick with alpha or Čech. Those complexes respect the metric exactly. Witness complexes approximate it.

— field note from a robotics persistent homology workflow, 2024

When data is low-dimensional — Čech or alpha complexes are cheaper and exact

Here is the irony most tutorials skip: witness complexes were invented for high-dimensional point clouds where full complexes explode combinatorially. In 2D or 3D, that justification evaporates. An alpha complex on 5000 points in the plane builds fast — O(n log n) — and gives you the homotopy type of the union of balls. A witness complex on the same data? Slower setup, worse fidelity, and you still have to tune the landmark selection. I have benchmarked this. For 300 points in ℝ³, a Vietoris–Rips complex completes in under two seconds on a laptop. A witness complex with 40 landmarks takes three seconds and produces a filtration that misses a connected component visible in the Rips output. The catch kicks in below 1000 points: the cost of building a full complex is trivial, yet people default to witness complexes because a textbook said they're "efficient." They're not efficient in low dimensions. They're wasteful. If your ambient dimension is ≤ 5 and your point count is ≤ 2000, skip the witness machinery. Use alpha if you have coordinates. Use Rips if you only have distances. You get exact persistence diagrams with fewer knobs to twist.

When the goal is persistent homology of a small dataset — under 1000 points

Small datasets expose the worst property of witness complexes: instability under landmark choice. Run the same 500-point cloud through a witness complex with 50 landmarks sampled randomly. Run it again with a different seed. The persistence diagrams diverge — barcode endpoints shift, some classes vanish entirely. With 500 points you can compute the full Rips filtration in milliseconds. There is no reason to inject randomness into your pipeline unless you're testing reproducibility across landmark strategies. Most teams I see revert to full complexes exactly here. They realize the witness complex was solving a problem they didn't have. The problem was speed for millions of points. They had 800. What usually breaks first is confidence: a reviewer asks "how did you pick landmarks?" and the answer is "we tried three seeds and averaged." That's not rigorous. For small data, exact methods win. Use Rips. Use alpha. Use the Delaunay triangulation if you need the nerve of a covering. Witness complexes are a tool for the regime where exact computation is infeasible. Don't use them where infeasibility is not the constraint.

Open Questions / FAQ

Does the witness complex preserve the homotopy type of the underlying space?

Short answer: not automatically, and certainly not in the way Čech complexes do. The witness complex trades homotopy guarantees for computational speed. Landmark points introduce a sampling bias—if your landmarks cluster in high-density regions and ignore sparse areas, the resulting complex can contract holes or merge connected components that should stay separate. I have debugged exactly this: a team ran a witness pipeline on point cloud data from a LIDAR scan, got a clean loop, and only later realized the loop was an artifact of uneven landmark selection. The correct homotopy type only emerges when the landmark set is a sufficiently dense sample of the underlying space. Nobody agrees what 'sufficiently' means in practice. A rule of thumb: if your landmarks miss a topological feature smaller than the local feature size, that feature disappears. You won't get a warning.

How to choose k adaptively based on local density?

Most teams fix k globally—say, k=6 for every landmark. That works fine until density shifts. Sparse regions: small k means your witness complex fragments into isolated cliques. Dense regions: large k includes far-away points as witnesses, drowning local structure in noise. The catch is—adaptivity itself introduces a new hyperparameter problem. I have seen practitioners try distance-thresholded k (grow k until the k-th nearest neighbor exceeds a radius R) only to find that R breaks the witness condition for sparse areas. What usually breaks first is memory: adaptive k per landmark means each landmark's witness list has different lengths, so you can't vectorize the construction. A simpler workaround: run a quick density estimate, bin landmarks into low/medium/high density groups, assign k values per bin. Not perfect, but it preserves coarse topology better than one-size-fits-all k. Expect to iterate the bin boundaries twice before they stabilize.

Can witness complexes handle stratified spaces with varying dimensions?

Stratified spaces are where witness complexes quietly fail. Consider a 2D surface intersecting a 1D curve. Near the intersection, a fixed k treats points on the curve as neighbors to surface points, creating spurious simplices that connect two strata that touch but should remain distinct in the complex. Wrong order: the complex sees topological noise, not a clean intersection. A colleague working on motion capture data (human poses occupy a low-dimensional manifold, plus occasional jumps that form a separate stratum) abandoned witness complexes entirely for this reason. The alternative? Build separate witness complexes per stratum using labels, then glue them together with a nerve complex on the intersection strata. That sounds complicated—it's. But the witness complex alone can't distinguish tangential contact from genuine topological connection. Stratified data demands explicit stratification in the construction step. Skip this, and your coarse topology collapses into a tangled mess. One rhetorical question worth asking: would you trust a single distance threshold to separate two intersecting manifolds of different intrinsic dimension? Probably not.

— the engineering cost of adaptivity is real, but ignoring strata costs you correctness.

Summary + Next Experiments

Recap: landmark ratio and k are the two levers — test them systematically

The pattern is brutally simple. You hold two knobs: the landmark-to-data ratio and the neighbor count k. That’s it. Everything else — choice of metric, landmark selection scheme — amplifies or dampens those two. I have watched teams spend three weeks tweaking a fancy farthest-point sampling variant, only to discover their real problem was k set too low for the density variation in one corner of the point cloud. The catch is that neither lever acts alone. A high landmark ratio with a tiny k kills coarse topology just as fast as a skinny landmark set with a huge k. Systematic testing means holding one fixed while stepping the other — not jiggling both at once. Wrong order. Start with landmark ratio: run it at 10%, 20%, 40% of the full dataset. For each ratio, sweep k from 3 to maybe 15, in steps of 2. That's maybe thirty combinations on a small dataset. A weekend of computation, and you see the failure modes surface.

Suggested experiment: compute persistence diagrams for a range of landmark counts and k values on a small dataset

Pick a dataset you know. Something small enough that a full Čech complex runs in under a minute — maybe three hundred points from a noisy circle plus some outlier clutter. Compute persistence diagrams for that full complex as your reference. Then run the witness complex at every combination of landmark ratio and k described above. What usually breaks first is the H1 feature — the loop that should persist across scales gets split into two short bars or disappears entirely. That thinning is the witness complex telling you it's losing coarse topology. Compare the diagrams by eye first. Spot the missing bars. Then — and this is the trick — compute bottleneck distance to the full Čech diagram. A single number masks failure modes, but it gives you a cutoff: if bottleneck distance jumps above 0.15 (pick your epsilon), that combination of levers is unsafe for your problem. Most teams skip this calibration. They deploy a witness complex, see one diagram that looks okay, and ship. Six months later the seam blows out because a new batch of points lands in an under-sampled region.

What if your bottleneck distance looks fine but the persistent homology barcode shows weird noise at low thresholds? That signals over-connectedness from too high k — you're pulling in non-neighbors that bridge genuine gaps. The fix is boring: lower k by 2, re-run, check again. Not glamorous, but it beats reverting to a full complex that costs ten times the memory.

You can't tune what you can't compare. The ground truth complex is your anchor — use it or guess blindly.

— One engineer's notebook after burning two weeks on an untuned witness complex

Compare bottleneck distance to a full Čech complex as ground truth

Run that comparison once, on a representative subset, and you own your parameters. Then store them — not as a vague guideline but as constants in your pipeline config. I have seen teams rebuild the same experiment from scratch every time a collaborator asks, "Why did you pick k=7?" Document the bottleneck distance table alongside the chosen settings. The long-term cost of a witness complex is not computational; it's the silent drift that happens when your data distribution shifts 5% and k=7 becomes k=3's problem. Re-run the calibration every time your dataset grows by 20% or your sampling regime changes. That sounds like overhead — it's. Less overhead than debugging a mysterious topology gap six months later. Next step: take your current dataset, run the sweep tonight, and email yourself the results table. Tomorrow you know whether the witness complex holds or leaks. That's one concrete action. Do it.