Cross-team Collaboration

Roles and what they need

Different people need different things from a Connectify project:

• Researchers want to prototype quickly, run ablations, and keep failed attempts around for context.
• Engineers want a stable, reviewable graph they can wire into production.
• Product managers and stakeholders want the result, the inputs, and confidence the analysis is sound — without becoming Connectify experts.

The patterns below resolve those tensions.

Workspaces and permissions

Set up a team workspace from the Hub. Inside, projects inherit role-based defaults:

• Researchers get Editor on research projects, Viewer on shipped pipelines.
• Engineers get Editor on shipped pipelines, Viewer/Commenter on research projects.
• PMs and stakeholders get Viewer everywhere.

Override per project from the Share dialog when needed.

Pattern: research → engineering handoff

1. Researcher tags the candidate

   When a variant looks shippable, the researcher right-clicks the variant tab → Tag → "candidate". The tag travels with the variant in version history.

2. Engineer forks for productionization

   Engineer forks the project into the team workspace. The fork is independent — engineering changes don't backflow into the research project, and the researcher's continued exploration doesn't break the engineer's stable copy.

3. Engineer leaves comments for clarification

   Anywhere the graph is unclear, engineer comments on the relevant node and mentions the researcher. Resolved comments collapse but stay in history.

4. Engineer hardens the graph

   Replace stub Datasets with production sources. Replace experimental Logic nodes with internal Custom nodes. Pin data versions and model checkpoints.

5. Tag the shippable version

   Once green, version-tag the project (v1.0). The tag is what gets wired into the production runner.

Pattern: living analysis for stakeholders

For dashboards and recurring analyses that PMs check on:

• Share the project as Viewer link — no login required for the recipient.
• Pin the latest run so the link always opens with results visible.
• Draw a path from the headline metric back to the inputs. Stakeholders see exactly what produced the number.

Pattern: code review on a graph

Graphs are reviewable too. Open History → Compare between two versions to see:

• Added/removed nodes.
• Config diffs on existing nodes.
• Wiring changes.

Leave review comments inline on the diff. Approving the diff merges the change into the project's main version.

Avoiding common pitfalls

"Who broke the graph?"

History shows who changed what. Use it instead of guessing — and use it as a learning tool, not blame.

"I can't tell what this node does"

Add a description in the node's Notes field. Notes show in tooltips and in the Inspector for everyone after you.

"My changes got overwritten"

If you're about to make exploratory edits, fork first. Forks are cheap; conflict resolution under last-writer-wins is annoying.