Sharing scouting with your team: a coach's guide to read-only opponent databases

A common pattern in junior fencing: three teammates from the same club fence in the same regional, see most of the same opponents, and don’t share notes.

It’s not malicious. It’s the friction of sharing notes that aren’t written down in a shareable form. The lefty foilist with the flick that fencer A faced in the round of 32? Fencer B doesn’t have notes on her either, and there’s no easy way for fencer A to give B her impression in a way B will actually pull up before fencing her at the next event.

This post is about the workflow that fixes that — without anyone having to edit anyone else’s notes.

The problem with edit-able shared databases

The first instinct, faced with the “share your scouting” problem, is to build a shared database that everyone on a team can edit.

This breaks in three ways.

Ownership ambiguity. Whose note is whose? If everyone edits the same opponent record, conflicting impressions overwrite each other. Fencer A wrote “fast counter-attack.” Fencer B writes over it with “slow counter-attack.” The disagreement contains useful information; the merge destroys it.

Trust degradation. A note written by someone you trust is different from a note written by someone whose judgment you’re still calibrating. A shared edit model erases the source of the note. You don’t know whether “don’t give him the hand” came from your head coach or a new club member.

Editing fatigue. Shared databases require coordination. Coordination requires meetings or norms. Most clubs don’t have either.

The read-only model

The cleaner approach is read-only sharing.

Each fencer owns their own scouting database. Their database is the source of truth for what they think. When they want to share with a teammate, they share their whole database as a read-only view. The teammate can see every opponent in it, every note, every rating — but they can’t edit anything.

The teammate then has the option of copying a specific opponent into their own database, where it becomes a fresh record they can edit and add to. The copy is a snapshot, not a sync; the original keeps changing independently.

This solves all three problems. Ownership stays clear (you own your database, I own mine, neither of us can change the other’s). Trust is preserved (when you share with me, I know your notes are yours and weight them accordingly). Editing fatigue disappears (there’s no coordination — you keep your notebook, I keep mine, occasionally we read each other’s).

It also captures the social reality of a club: some coaches and fencers’ scouting is more accurate than others’, and a healthy team understands the difference rather than papering over it.

How Piste IQ implements this

The read-only model is the default sharing mode in Piste IQ. Two share types:

Database-level share. Send your entire scouting database to a teammate. They see everything in it, ongoing — including opponents you add later. They can’t edit; they can copy.

Profile-level share. Send a single opponent profile to a teammate, as a one-time copy. The recipient accepts it into their own database, where it lives independently. Updates to your original don’t flow through.

Database-level sharing is the right pattern for ongoing team coordination (“we all share with the head coach, who has the union of everyone’s intel”). Profile-level sharing is the right pattern for one-off scouting handoffs (“you’re seeded against someone I fenced last month, here’s what I know”).

A workflow that actually gets used

Sharing patterns die when they require effort to maintain. Here’s a workflow that’s lightweight enough to survive a busy season.

Once per club, set up cross-shares. Every fencer on the team shares their database with the head coach as read-only. The head coach now has a union view of everyone’s scouting, automatically updated.

Pre-tournament, the coach can hand out scouting on demand. If fencer B is up against an opponent fencer A has notes on, the coach pulls A’s notes and tells B what’s worth knowing — or shares A’s profile of that opponent directly into B’s database for B to read later.

Post-tournament, everyone updates their own database. Reflection happens individually. No shared-edit conflicts. Each fencer’s database keeps growing on its own.

Once per season, prune. Old age-category opponents who you’ll never fence again can be archived or deleted. Your most-fenced rivals get the most attention. The database stays usable rather than ballooning into noise.

Sharing with parents

A specific case worth flagging: parents of competitive fencers often want to track scouting alongside their kid, but the kid is the one fencing and therefore the one with first-hand data.

The clean pattern here is exactly the same as the coach pattern. The fencer maintains their database; they share it read-only with their parent. The parent now has visibility into who their kid has fenced and what they’ve learned, without being able to edit the kid’s notes — which is the right boundary in most family-coaching dynamics.

Piste IQ’s coach mode is set up to support both parents-as-coaches and team-coaches-as-coaches with the same primitives.

When to break the read-only rule

There’s a small set of cases where read-only sharing isn’t enough.

The most common: a head coach who wants a single team scouting book for tactical planning. In this case, the coach should maintain the master database themselves — fencers can share their individual scouting to the coach, and the coach curates the master.

In Piste IQ’s current model this is implemented by: every fencer shares to the coach, the coach uses their own database as the master, and when they pull intel from a fencer’s shared view they copy the relevant profile into the master with attribution in the notes. It’s a one-way pipeline rather than a collaborative document, and that’s actually the right structure for tactical coaching.

The deeper point

Scouting is information. Information has owners. The cleanest team scouting model preserves who-said-what while making it easy to share across the team.

Read-only sharing — with the option to copy into your own database — is what that looks like in practice. It’s not the only model that could work, but it’s the one that survives the realities of a competitive season.