Handbook of Graphs and Networks in People Analytics

1. 1State the question first: you want who is influential by virtue of whom they are connected to, not merely how many people they know. If the question is only about volume of ties, use degree centrality; if it is about bridging or reach, use betweenness or closeness.
2. 2Build the adjacency matrix A for the graph with p vertices: a_ij = 1 if i and j are adjacent, 0 otherwise (unweighted case). Confirm the vertex set and edge list before computing anything.
3. 3Solve Ax = λx, requiring x to have only positive entries. This gives a unique solution with the maximum eigenvalue λ. Take that x and that λ, not any other eigenpair.
4. 4Compute each vertex's score as (1/λ) × Σ a_vw x_w over all vertices w. Each vertex's score is a function of the scores of its neighbors, which is why a single linear system captures influence.
5. 5Do not compute by hand in practice. The source covers calculating in R and in Python, so use the centrality function in your graph package, and cross-check on a small graph such as Zachary's Karate Club (karate data in the onadata package).
6. 6Compare against degree, closeness and betweenness for the same vertices. Where eigenvector rank diverges from degree rank, inspect that vertex's neighbors: either many low-influence ties or a few high-influence ties is driving the score.
7. 7If the graph is directed, split the measure: outgoing eigenvector centrality is the hub score, incoming is the authority score. In undirected graphs hub score, authority score and eigenvector centrality are identical, so report only one.
8. 8Treat edge weights as a deliberate choice. Weights are unusual in centrality measures and remain an area of ongoing research, so state whether you used them and why.

The source's graph G14 illustrates the logic. Vertex 4 has the highest degree centrality, and intuitively it also has the highest eigenvector centrality. Vertex 10 has an eigenvector centrality of 0.12, while Vertex 2 has 0.23, nearly double. The explanation is that Vertex 2 is connected to Vertex 4, the best-connected vertex in the network, so it inherits influence from that tie. Vertex 10 lacks an equivalent link to a highly influential neighbor. The lesson is that the number of connections alone does not decide the score; who those connections are does. To check the pattern yourself, compute degree, closeness, betweenness and eigenvector centrality side by side for the same vertices and see where the rankings differ.

• If you care about being tied to powerful people rather than raw connection count, use eigenvector centrality; if you only need ties counted, use degree.
• If the graph is undirected, report a single eigenvector centrality; hub and authority scores are identical there and add nothing.
• If the graph is directed and you want to separate those who cite or point to influential nodes from those who are pointed to by them, use hub score (outgoing) and authority score (incoming).
• If a vertex scores high on eigenvector centrality but low on degree, look for a small number of highly influential neighbors; if it scores high on both, it may simply be a well-connected hub.
• If your question concerns overall network connectivity or the effect of removing someone, bring in betweenness and closeness; the source ties betweenness to disconnection risk when people leave.

• Treating eigenvector centrality as a synonym for popularity. The tell: you explain a high score only by the number of ties, and never examine who the neighbors are.
• Assuming one centrality measure covers all roles. The source states that degree, betweenness, closeness and eigenvector centrality imply different roles; the tell is that you report one ranking and the Karate Club-style comparison would reorder the people.
• Reporting hub and authority scores separately on an undirected graph. The tell: the two columns are identical.
• Ignoring edge weights without saying so, or assuming the standard computation reflects tie strength. The tell: strong and weak ties produce the same scores, and your conclusions about influence rest on that unstated choice.
• Reading the score as a causal or lasting measure of influence, or assuming preferential attachment explains it. The source notes recent research finds scale-free networks rare and social networks at best weakly scale-free; the tell is a narrative about accumulated advantage with no supporting evidence.

• ▸Question being asked: one line on whether you need influence-through-connections or just connection volume.
• ▸Graph type: undirected or directed; unweighted or weighted.
• ▸Vertex count (p) and source of the edge data: record where the adjacency matrix came from.
• ▸Weighting decision: state whether edge weights are used and the reason.
• ▸Top 5 by eigenvector centrality: list vertices with scores.
• ▸Top 5 by degree centrality: list vertices to compare against the eigenvector list.
• ▸Rank divergences: note each vertex ranked differently and who its neighbors are.
• ▸Hub and authority scores (directed only): record both and what they imply.
• ▸Interpretation and caveat: one sentence on what the scores mean, plus one limit.

1. 1Fix what an edge means before you compute anything. Distance is only as meaningful as the tie behind it: a reporting line, an email exchange or a shared meeting each yield different distances. The source says distance can represent familiarity, likelihood of similarity, or the chance information reaches someone. Write one sentence naming the question the distance answers (for example, 'how likely are these two people to know each other').
2. 2Build the graph from an edgelist of vertex pairs, one row per tie. Decide whether ties are directed, because distance from A to B may differ from B to A. Add edge properties only if they are real costs, as maps do with road length, speed limit and live traffic.
3. 3Choose hop distance or weighted distance. Hop distance is the number of edges on the shortest path. If edges carry a cost, run a weighted shortest-path method such as Dijkstra's algorithm. If you cannot defend the weights, use hops.
4. 4Compute shortest paths between the pairs you care about before computing everything. A single-pair path answers an introduction request ('who connects Ana to Raj?'). The all-pairs distance table feeds diameter and group analysis.
5. 5Compute the diameter as the largest of all shortest-path distances. Read it as the worst-case separation: the number of hops between the two most distant people. Report it next to density, since the source pairs the two, and a sparse graph and a large diameter tend to go together.
6. 6Check connectivity first. If some pairs have no path, the diameter and average distance are undefined or misleading for the whole graph. Compute them per connected component and report the component sizes.
7. 7Read distances as a distribution, not one number. For tightness, compare distances within a group with distances between groups, which is how the source describes measuring intra- and inter-group interaction. List the most distant pairs, which is the 'find distant colleagues' use.
8. 8Turn the result into an action. For introductions, take the shortest path and ask the intermediate person(s) to make the link. For diverse groupings, assign people so that members of the same subgroup sit at high mutual distance. Then check the resulting distances against the original graph.

The book's own use cases are facilitating workplace introductions and finding distant colleagues to build diverse groups. This sketch is a hypothetical five-person network built to show the mechanics, not data from the book. Edges: Ana–Ben, Ben–Cai, Cai–Dee, Dee–Eli, so the graph is a chain. Ana's shortest path to Eli is four hops (Ana, Ben, Cai, Dee, Eli). Every other pair is closer, so the diameter is 4 and Ana and Eli are the most distant pair. To introduce Ana to Eli, you do not search for a link: the shortest path names Ben, Cai and Dee, and Dee, one hop from Eli, is the natural person to ask. For a two-person lunch group that maximizes in-group distance, you pair Ana with Eli, not Ana with Ben, because distance stands in for low familiarity and so a more diverse mix. If you add one edge, Ana–Eli, the diameter falls to 2 and the chain becomes a ring. One tie changes how reachable everyone is, which is why you recompute after any edge change.

• If the question is 'will information or an introduction reach this person?', use the shortest path between that pair and the intermediaries it names, not the diameter.
• If you want to mix people who do not know each other (events, project teams, meeting invitations), then pick groups that maximize in-group distance and verify with the all-pairs table.
• If the graph has disconnected pieces, then report distance and diameter per component, never one global figure.
• If edges have defensible costs (time, length, interaction strength), then use weighted shortest paths. If they do not, use hop counts and say so.
• If the diameter looks small, then check density and edge definition before concluding the organization is 'well connected'. A permissive tie definition shrinks distances.

• Treating hop distance as true familiarity. The tell: two people at distance 1 who never work together, because the edge came from a broad source such as a mass email list.
• Quoting one diameter for a graph that has disconnected components. The tell: infinite or missing distances, or a diameter that describes only the biggest cluster.
• Using unweighted hops where edges carry real costs, or weights nobody can justify. The tell: the 'shortest' path routes through a person or link that is practically unusable, or the ranking flips when weights are slightly changed.
• Ignoring direction. The tell: A reaches B but B cannot reach A, and the reported path is unusable for the introduction you wanted.
• Reading the diameter as typical separation. The tell: one outlier pair sets the diameter while most pairs sit far closer, so the figure misstates the network's ordinary distance.

• ▸Question being answered: one sentence on what distance represents (familiarity, information reach, introduction path).
• ▸Edge definition: what a tie is, its source data, and whether it is directed.
• ▸Distance type: hops or weighted; if weighted, name the edge property and its unit.
• ▸Component check: number of connected components and the size of each.
• ▸Target pair(s) or group(s): who you are measuring between.
• ▸Shortest path(s) found: the vertex sequence and its length for each target pair.
• ▸Diameter and most distant pair: the value and the two vertices, computed per component.
• ▸Density: recorded alongside the diameter for context.
• ▸Action and recheck: the introduction made or grouping chosen, and the date you recompute distances after edges change.

1. 1Fix the unit and the edge meaning before any algorithm runs. Decide who or what the vertices are and what an edge represents (worked with, friend of, spoke in the same scene). Build an unweighted, undirected graph first, as the Friends exercise does, and add weights only after the basic structure is clear.
2. 2Check connectivity and split into connected components. Components are the coarsest partition: a vertex has no path to anything outside its component. Analyze each component separately and note any isolated pieces, because a community search over a disconnected graph mixes two different questions.
3. 3Run community detection (graph partitioning) in igraph (R) or networkx (Python). It returns a membership label per vertex. Treat the label as a vertex property and attach it to the graph so you can color, filter, and summarize by it.
4. 4Search for cliques separately. A clique is a subgraph in which every vertex is connected to every other, so its density is 1. Look for the largest clique and for cliques that exclude the obvious hubs. Communities are loose pockets; cliques are the strictest case inside them.
5. 5Quantify how tight each group is. Take each community or clique as a subgraph and compute its density, its diameter, and the distances inside it. The source treats distance and diameter as measures of how 'tight' groups are and of inter- versus intra-group interaction. Compare the within-group figures against the whole graph.
6. 6Test robustness by removal. Delete the most connected vertices (the Friends exercise removes the six main characters), then recheck connectivity, component diameters, and the largest clique. Structure that survives was never held up by those hubs.
7. 7Describe each community with ground-truth properties you already hold, such as department, age group, or party. The high school and Twitter-politician examples in Chapter 7 do this. Check whether the detected pockets line up with the known attribute, and say so in plain words.
8. 8Visualize with membership as color, then name what each pocket is and what decision it supports, such as group membership, meeting attendance, or organizational design.

The source's Friends TV network (an edgelist of characters linked by speaking in the same scenes) works as a clique drill. Build it as an unweighted, undirected graph and check whether it is connected. Then extract the subgraph of the six main characters (Monica, Chandler, Phoebe, Ross, Rachel, Joey) and compute its density. If the density is 1, every pair is connected and the group is a clique. This is the tightest possible pocket, and you read it against the full-graph density. Next, remove those six characters and check whether the remainder is still connected. If it breaks into pieces, the main cast was the bridge holding the network together. Compute the largest diameter among the remaining connected components and identify the pair of characters at its ends. Finally, find the largest clique in the reduced graph, and look for one that contains no main character. A clique that appears with the main cast gone shows that dense pockets exist outside the center of the network. A graph that fragments after removal shows that the center, not the pockets, supplied the connectivity.

• If the graph is disconnected, then split it into connected components first and run community detection inside each, rather than reading components as communities.
• If you need a strict, all-pairs-connected group, then search for cliques (density 1). If you need looser pockets of intense interaction, then use community detection.
• If a complete graph is the target, then drop it: whole-graph completeness is rare and uninformative. Look for complete subgraphs inside the graph instead.
• If the detected communities do not line up with a known attribute (department, party, school group), then check the edge definition and the partition before drawing conclusions about the organization.
• If the structure collapses when the highest-degree vertices are removed, then report the pockets as dependent on those hubs, not as independent communities.

• Treating connected components as communities. The tell: one giant component gets labeled 'the community' and tells you nothing about internal pockets.
• Mistaking a dense-looking drawing for a clique. The tell: the group looks tight on the plot but its density is below 1 when computed.
• Reporting membership labels without describing them. The tell: a color-coded plot with no comparison to ground-truth attributes, so no one can say what the groups are.
• Searching for cliques only among well-known hubs. The tell: the largest clique always contains the main characters or the most connected staff, and no one has checked the graph with them removed.
• Choosing an ambiguous edge meaning, or mixing weighted and unweighted views. The tell: communities change shape when the edge definition changes, and no one can say which version is correct.

• ▸Vertices and edge meaning: state what a vertex is and what a connection means, and whether the graph is directed or weighted.
• ▸Connectivity check: record whether the graph is connected and the number of components with their sizes.
• ▸Detection method used: record the community detection or partitioning function (R igraph or Python networkx) and the number of communities found.
• ▸Community profile: for each community, record size, internal density, and diameter.
• ▸Largest clique: record its members and size, and note any clique that excludes the main hubs.
• ▸Hub-removal test: list the vertices removed, and record whether the graph stays connected and what the largest clique becomes.
• ▸Ground-truth match: record the known attribute (department, party, group) and how well it aligns with each community.
• ▸Decision supported: state the use (group membership, meeting attendance, organizational design) and the action it implies.

1. 1Define the property first. Use a categorical property (department, political party, class) for nominal assortativity, or a numeric property (degree) for degree assortativity. The coefficient is defined differently for each (Newman 2002), so the choice changes what the number means.
2. 2Define the edge and its direction. State what counts as a connection (reported friendship, Facebook link, email, calendar, timesheet, document collaboration) and whether the graph is directed. The same people can produce different assortativity under different connection definitions.
3. 3Build the graph with vertex properties attached (see the Chapter 2 steps for adding properties to vertices and edges). Confirm that every vertex has a value for the property. Missing ground-truth properties are the reason Chapter 8 offers vertex similarity as a fallback.
4. 4For degree assortativity in R, run igraph::assortativity_degree(graph). For a categorical property, use the nominal assortativity function with the property mapped to integer categories. The Python equivalents are in section 8.4.
5. 5Read the coefficient like a correlation on a −1 to 1 scale. Near 1 means vertices with the same property are very likely to connect (assortative). Near −1 means they strongly avoid each other (disassortative). Near 0 is neutral. Do not call a value 'high' without this anchor.
6. 6Interpret for degree: a high value means preferential attachment. Highly connected vertices link to each other, and a large number of low-degree vertices make up the rest of the network.
7. 7Translate into the tradeoff. High assortativity means resilience to vertex loss, because knowledge and social capital sit in a strong core. It also means inefficient information flow, weaker diverse interaction, and a harder environment for new entrants.
8. 8Run the same calculation across alternative connection definitions (e.g., Facebook versus reported friendships) and compare. Report the gap between the two networks alongside the coefficient.

The book computes degree assortativity on two schoolfriends networks. Facebook friendships (undirected) give igraph::assortativity_degree(schoolfriends_fb) = 0.0246. Reported friendships (directed) give assortativity_degree(schoolfriends_rp) = 0.3098. On the −1 to 1 scale, Facebook is approximately neutral and real-life reported friendship is moderately assortative. The interpretation is that more popular students are more likely to be friends with other popular students in real life, while the Facebook network shows almost no such sorting. The two graphs share the same students but use different definitions of connection. That is why the book pairs assortativity with graph similarity, which asks whether two definitions of connection produce substantially the same network. In an organization, a 0.31-type result would point to a concentrated core: resilient to departures, but a harder place for newcomers to break into.

• If the coefficient is near 0 (like 0.02 for Facebook friendships), then call the network neutral and do not claim homophily or a core.
• If degree assortativity is clearly positive (like 0.31), then expect a concentrated core of well-connected vertices. Treat the network as resilient to departures but a risk for inclusion and information flow.
• If the property is department or party, then use the categorical version. If it is degree or another number, then use the numeric version. Never compare coefficients across the two types as like-for-like.
• If you lack ground-truth vertex properties, then use vertex similarity from shared neighbourhoods instead of assortativity.
• If you expect social networks to be assortative by default, then check first. Research on directly measured ties (Fisher et al. 2017) suggests they are likely neutral, and that social networks are more assortative than non-social ones.

• Assuming social networks are always degree assortative. The tell: you read a near-zero coefficient as an error instead of a plausible neutral result.
• Treating high assortativity as simply good (resilient) or simply bad (siloed). The tell: your report states only one side of the resilience versus diversity and efficiency tradeoff.
• Mixing property types or definitions. The tell: you compare a categorical department coefficient with a degree coefficient, or an undirected network with a directed one, as if equivalent.
• Using one data source as 'the network'. The tell: you report a single coefficient when email, calendar, or reported-friendship data would give different values, as with 0.02 versus 0.31.
• Reading the number without the scale. The tell: you call a value 'high' or 'low' without anchoring it to −1, 0, and 1, or without linking it to preferential attachment.

• ▸Vertex property tested: name it and mark categorical or numeric.
• ▸Connection definition: state what an edge means (email, reported friendship, etc.).
• ▸Directed or undirected: record it, since it affects the calculation.
• ▸Property coverage: note the share of vertices with a value, and the fallback (vertex similarity) if coverage is poor.
• ▸Coefficient: record the value from the igraph or Python function.
• ▸Scale reading: mark assortative (near 1), neutral (near 0), or disassortative (near −1).
• ▸Resilience implication: say what a departure from the core would do to knowledge and social capital.
• ▸Diversity and efficiency implication: note effects on cross-group interaction, information flow, and newcomers.
• ▸Comparison network: give the alternative connection definition and its coefficient.

1. 1Fix the question before computing. Vertex similarity asks whether two people occupy the same position because they connect to the same others. Graph similarity asks whether two definitions of connection (two edge sets) draw the same network. Mixing the two produces uninterpretable numbers.
2. 2Build each graph from a clean edgelist or adjacency matrix with one row per connection (from, to), as in the londontube_edgelist layout. Confirm vertex IDs are identical across graphs before comparing anything.
3. 3For vertex similarity, list each vertex's immediate neighbors, N(a) and N(b). Count the neighbors in common and compare that count to the combined distinct neighbors of both vertices. Report the raw shared count next to the normalized score, because a raw count rewards well-connected vertices. The source passages only name Chapter 8.2 as covering vertex similarity, so check which formula your library implements before quoting a number.
4. 4Decide up front whether the pair itself counts. In an undirected graph, two directly linked vertices can share zero neighbors. Note this when direct ties are common in your data.
5. 5For graph similarity, build the alternative graphs on the same vertex set, for example customers linked through shared sales reps versus customers linked through common purchases (both are Chapter 4 constructions). Compare the edge sets: how many edges appear in both, and how many appear in only one.
6. 6Test the inference against an outside label. Run community detection and check it against a known attribute. In the workfrance example, Louvain communities line up with departments, which is evidence that the structure carries meaning.
7. 7Rank pairs by similarity and inspect the top and bottom by hand. Then act on the result: introductions, group composition, or deciding which definition of connection to carry forward.

The londontube_edgelist rows shown in the source give a small, real neighbor comparison. Station 11 connects to 163 and 212. Station 82 connects to 163 and 193. Station 49 connects to 87 and 197. Using only these displayed rows, N(11) = {163, 212}, N(82) = {163, 193}, N(49) = {87, 197}. Stations 11 and 82 share one neighbor (163) out of three distinct neighbors between them, a score of 1/3. Stations 11 and 49 share none, a score of 0. So 11 is more similar to 82 than to 49, because 11 and 82 both reach station 163. This is only the head() preview; the full edgelist would be needed before drawing any conclusion about the stations, and it would likely change the counts.

• If two vertices share many neighbors but are not directly connected, treat them as latent look-alikes and a candidate introduction. If they are already linked and share neighbors, treat them as embedded in the same cluster.
• If you compare a high-degree vertex with a low-degree one, read the normalized score, not the raw shared count. The raw count favors hubs.
• If two graph definitions of connection share most edges, either one can stand in for the other. If they share few, they measure different relationships, so keep both and name the difference.
• If similarity scores agree with an external grouping such as department, the edges encode that grouping. If they do not, check the data construction before concluding people are unlike their labels.
• If the graph is sparse, with few edges per vertex, do not rank pairs on one or two shared neighbors. Gather more connection data first.

• Comparing graphs with mismatched vertex IDs or different vertex sets. The tell: similarity is implausibly low, or vertices exist in one graph only.
• Reading a raw shared-neighbor count as similarity. The tell: the top pairs are all hubs.
• Calculating on a preview of the data, such as the head() rows, and treating the result as final. The tell: neighbor lists of exactly two entries.
• Confusing vertex similarity with distance or community membership. Distance can signal likely similarity, but it is a different measure from shared neighbors. The tell: you cite path length when asked about common contacts.
• Inferring that similar structure means similar attitudes or skills without outside evidence. The tell: no attribute or label is checked against the scores.

• ▸Question type: vertex similarity or graph similarity, in one line.
• ▸Graph source(s): the edgelist or matrix each graph came from, and the connection definition each encodes.
• ▸Vertex ID check: confirm the same ID set appears in every graph being compared.
• ▸Vertex pair(s): the two vertices under test.
• ▸Neighbors of A and B: list N(a) and N(b) explicitly.
• ▸Shared neighbors / combined distinct neighbors: record both the count and the ratio.
• ▸Edge-set overlap (graph comparison): edges in both, edges in graph 1 only, edges in graph 2 only.
• ▸External check: the department, group or label used to test the result, and whether it agrees.
• ▸Action and caveat: the decision this supports (introduction, grouping, or choice of connection definition) and the main data limitation.

1. 1Decide whether persistence is warranted. If your organization repeatedly analyzes connections and relationships, move to a graph database to make the analysis 'oven ready'. If you run a one-off analysis, keep the data in a rectangular table and build the graph in memory.
2. 2Choose the model. A labelled-property graph (e.g. Neo4J) stores defined properties on nodes and edges. It is easier to query but less flexible when data structures change rapidly. RDF is a powerful relationship storage engine, but the passages say it has a high expertise bar: complex query and traversal, plus detailed knowledge of codes for properties and values. Default to labelled-property unless you need RDF.
3. 3Stand up a sandbox first. Create a free Neo4J Aura instance: go to neo4j.com/cloud/aura, click 'Start Free', register a database in a region of your choice and name it. Record your URI, username and password, because every R or Python connection needs all three.
4. 4Design the schema as vertices, edges and properties. Map each rectangular-table field to one of the three. For example, a person is a vertex labelled Person with name and party properties, and an interaction is an edge such as INTERACTED_WITH. Keep the schema general enough that unrelated networks can coexist in it.
5. 5Load a known data set and test it. Use the browser interface to load and inspect the data, then connect programmatically from R or Python with your_URI, your_username and your_password. Run a Cypher MATCH ... RETURN query and check that the rows are what you expect.
6. 6Check structure with APOC procedures. Run CALL apoc.stats.degrees('>'); and confirm the total, percentile and max degree values match what you computed on the source data before trusting the store.
7. 7Automate the ETL. Write an Extract, Transform, Load job in R, Python or another platform. It extracts from the rectangular databases, transforms the data into vertices, edges and properties, and loads it incrementally into the graph. Schedule it on a server at your reporting cadence (weekly, monthly or whatever fits).
8. 8Query repeatedly from analysis code. Pull Cypher results into your analysis environment (for example as a list of dicts converted to a pandas DataFrame) and run your network analysis from there, rather than rebuilding the graph from raw tables each time.

The source loads its ontariopol data set, the Twitter network of Ontario state politicians from Chapter 7, into a Neo4J Aura database. From Python, the query MATCH (p:Person)-[:INTERACTED_WITH]->({party: 'IND'}) RETURN DISTINCT p.name AS name, p.party as party; returns a list of dicts. These convert to a pandas DataFrame, and the head shows rows such as Ernie Hardeman (PCP), Kinga Surma (PCP) and Sara Singh (NDP). So the query finds people who interacted with independents, and the party property comes straight from the graph. A structural check follows: CALL apoc.stats.degrees('>'); returns outgoing-degree statistics with a total of 6095, a median (p50) of 59, a maximum of 80, a minimum of 7 and a mean of about 56.4. Neither result required rebuilding the graph from a table. The source adds that the schoolfriends graph could be loaded into the same schema, because the two networks are completely different but can coexist.

• If your analysis of relationships recurs on a reporting cadence, then persist the data in a graph database and automate the ETL. If it is a one-off, then skip the database.
• If your data structures change rapidly, then favor RDF's flexibility. If you need easier querying and your team lacks deep RDF expertise, then choose a labelled-property graph.
• If you are learning or prototyping, then use a free Neo4J Aura instance, not production infrastructure.
• If several networks serve different use cases, then store them in one graph schema, because a graph database handles many data types for many use cases.
• If you want to explore RDF without committing, then use the Wikidata Query Service and its Query Builder, which helps non-SPARQL experts build queries.

• Adopting RDF without the expertise. The tell: queries stall on traversal complexity and property or value codes nobody on the team understands.
• Treating persistence as a one-time load. The tell: the graph drifts from the source tables because no scheduled, incremental ETL exists.
• Choosing a labelled-property graph, then redesigning the data structure often. The tell: repeated schema rework, because labelled-property graphs are less flexible with rapidly changing structures.
• Losing the connection credentials. The tell: you cannot connect from R or Python because the URI, username or password was not recorded at setup.
• Building a persistent graph for analysis that does not recur. The tell: infrastructure cost with no repeated queries, where a rectangular table and an in-memory graph would do.

• ▸Recurring question: state the connection or relationship analysis you run repeatedly.
• ▸Reporting cadence: weekly, monthly or whatever fits your reporting.
• ▸Source tables: list the rectangular databases to extract from.
• ▸Graph model: labelled-property or RDF, with one-line justification (structure volatility, team expertise).
• ▸Vertex labels and properties: e.g. Person with name and party.
• ▸Edge types and properties: e.g. INTERACTED_WITH.
• ▸Other networks sharing the schema: list any additional data sets to co-locate.
• ▸ETL platform and schedule: R, Python or other, plus server run interval and incremental-load rule.
• ▸Validation checks: sample Cypher queries and degree statistics (e.g. apoc.stats.degrees) to compare against source.

1. 1Name the single outcome before touching data. Pick from the list the passages support: socializing new hires, inclusion and belonging, diverse collaboration and interaction, collaboration overload and burnout, productivity, retention, well-being, office utilization, efficient communication strategies, or information flow. One outcome per analysis keeps the network question testable.
2. 2Translate the outcome into a network question at a specific level of analysis. The foreword says network analysis lets you zoom in or out: the centrality of a specific individual, or the centralized structure of an entire organization. A new hire's integration is an individual-level question. Information flow across the organization is a whole-graph question.
3. 3Choose the data source that matches how the connection is defined. The passages list digital communication platforms, surveys and HR information systems. Connection can be in-person interaction, electronic transaction, or assumed connection from overlaps in location or activity. State which definition you use and why it is meaningful to the outcome.
4. 4Build the graph from the data and visualize it first. Create the graph, then draw it, before computing measures. Use open source R or Python, as the book does.
5. 5Compute the measures that map to the outcome. Use density and centrality for individual and group connection. Use community-detection and partitioning algorithms to find intensely collaborative groups or to check whether new organizational structures reflect the actual flow of work. Compare the result against the outcome question from step 2.
6. 6Check indirect structure, not just direct ties. People judge indirect ties poorly, so use the graph to see who a person's contacts know. This is where the measure adds information that individual perception does not.
7. 7Plan the intervention and its evaluation together. The passages warn that even meaningful connection measures do not guarantee that interventions work as expected. Define in advance the outcome you will re-measure (for example, retention or engagement) alongside the network measure.
8. 8Protect privacy and trust in data collection. Decide how to gather and prepare the data without violating employee privacy and trust, and settle this before analysis, not after.

The Feld & Carter (1998) study, cited in the passages, shows why outcome-linked network analysis needs evidence. The goal was diverse interaction: schools deliberately tried to increase interracial contact. The intervention seemed obviously sound. Yet the study found it ended up causing greater racial segregation. The lesson is that a connection measure can look meaningful, and the intervention built on it can still miss the intended outcome. Applied to a workplace aiming at diverse collaboration or new-hire integration, you define the connection (for example, collaboration data from a communication platform), map the graph, and set the outcome you want to move. You then re-measure the graph after the change. If the graph shows more cross-group ties but the outcome does not improve, or segregation rises, the intervention has not worked. The source supports this check, not any particular numbers.

• If the outcome is about one person (a new hire's integration, a potential leader), then analyze at the individual level with centrality. If it is about the organization's information flow or structure, then analyze at the whole-graph level with density and centralization.
• If you want to find intensely collaborative groups or test whether the org chart matches the flow of work, then run a community-detection or partitioning algorithm and compare its groups to formal structure.
• If the connection measure has not been shown to relate to the outcome you care about, then do not intervene on it. Not all measures of connection are meaningful to every outcome.
• If an intervention is designed to increase contact or collaboration, then plan a follow-up measurement, because deliberate efforts can backfire, as the Feld & Carter finding shows.
• If the data would require intrusive collection, then resolve the privacy and trust questions first, or choose a less sensitive source such as surveys.

• Treating more connection as automatically better. The tell: you target tie counts without a linked outcome such as retention, engagement or burnout. The source notes collaboration overload and burnout as risks in their own right.
• Judging indirect ties by gut feel. The tell: conclusions rest on whom managers think people know. The foreword says accuracy diminishes for indirect ties, so compute them from the graph.
• Launching an intervention without measuring its effect. The tell: no post-intervention graph or outcome metric. The Feld & Carter result shows interventions can produce the opposite of what you intended.
• Defining connection loosely. The tell: assumed ties, such as shared location, are treated as real collaboration without checking meaning for the outcome.
• Collecting data at the cost of trust. The tell: employees resist or distrust the data gathering, which undermines the analysis and the program.

• ▸Target outcome: name one outcome (e.g., new-hire integration, diverse collaboration, retention, burnout, information flow).
• ▸Level of analysis: individual, group, or whole organization, with a one-line reason.
• ▸Connection definition: in-person, electronic transaction, survey, or assumed overlap, and why it is meaningful for the outcome.
• ▸Data source: communication platform, survey, or HR information system.
• ▸Privacy and trust plan: how you collect and prepare data without violating employee privacy.
• ▸Measures to compute: density, centrality, or community detection, and which question each answers.
• ▸Intervention hypothesis: what change you expect to improve the outcome.
• ▸Backfire check: how you will detect an opposite effect (the Feld & Carter risk).
• ▸Re-measurement plan: when you rebuild the graph and re-measure the outcome.

1. 1State the analytic question in one sentence before touching data (e.g., 'who has worked with whom?' or 'who manages whom?'). The question decides what a vertex is and what an edge means; the data only supplies candidates.
2. 2Define the vertex set V first. Name the entity type (people, airports, requests, subreddits) and list the unique entities. If you have only an edgelist, derive V from the unique entries in the 'from' and 'to' columns. This silently drops isolates, so decide on purpose whether that is acceptable.
3. 3Write the edge rule as an if-and-only-if sentence, as the source does: 'An edge connects two vertices if and only if those two people have worked together.' If you cannot finish the sentence unambiguously, the edge is not yet defined.
4. 4Decide direction from the relationship itself. Symmetric relationships such as 'worked with' are undirected edges. Asymmetric ones such as 'manages' or 'likes' are directed, and Zubin ⟶ Jane and Jane ⟶ Zubin are two different edges. Record direction as 'from'/'source' and 'to'/'target' columns.
5. 5Decide how to handle multiple relationships between the same pair. If you have several kinds (carriers on a route, 'worked with' plus 'manages'), either keep a multigraph with a type property on each edge, or collapse to one edge per pair with a weight (e.g., number of carriers). Choose according to whether the question needs the kinds kept separate.
6. 6Attach properties deliberately. Put weights and relationship types on edges, and entity attributes on vertices. Check that your edge-building code does not create self-loops or duplicate edges unless your graph type allows them (a simple graph allows neither).
7. 7Build the graph from an edgelist, adjacency matrix or dataframe. Then check it against your definition: count vertices, count edges, confirm direction, and regenerate the edgelist to see that it matches the data you intended.

The source builds G_work from four people: David, Suraya, Jane, Zubin. The edge rule is 'an edge connects two vertices if and only if those two people have worked together,' so edges are undirected. The edge set is {David–Zubin, David–Suraya, David–Jane, Jane–Zubin, Jane–Suraya}, and V can be read straight from the unique names in E. Next, define G_manage with the rule 'one person manages another.' This relationship runs one way, so the edges are directed. Defining G_like ('the first person has listed the second as someone they like') shows that edges can run both ways, because Jane ⟶ Zubin and Zubin ⟶ Jane are separate edges. Combining G_work and G_manage into one directed graph produces a multigraph, since the same pair can now hold two kinds of relationship. The airport example shows the alternative. PHL, SFO and TUS have multiple carriers per route, drawn as parallel edges. The graph is then simplified into weighted edges, where weight is the number of carriers on each route, shown as edge thickness.

• If the relationship is mutual by nature (worked together), then use undirected edges. If it has an initiator and a recipient (manages, likes), then use directed edges.
• If the same pair of entities is linked in more than one way, then use a multigraph with an edge-type property to keep the kinds separate. If you only need how strongly they are linked, then collapse to a weighted edge such as a carrier count.
• If your data is an edgelist and isolates matter to the question, then add them to the vertex set explicitly. Otherwise V derived from E drops them.
• If the graph has thousands of nodes and millions of edges, then rely on edgelist or adjacency-matrix definitions rather than diagrams. Diagrams do not scale for checking edge definitions.
• If your graph must be simple, then confirm there are no loops and no repeated pairs before analysis.

• Treating a directed relationship as undirected, or the reverse. The tell: a 'manages' graph where each pair shows a mutual edge, or a 'worked with' graph that counts A→B and B→A as two ties.
• Leaving the edge rule vague (e.g., 'connected'). The tell: two analysts build different edgelists from the same data.
• Collapsing multiple relationship types into one unweighted edge. The tell: parallel relationships disappear, and PHL–SFO looks the same as PHL–TUS even though the number of carriers differs.
• Dropping isolates without noticing. The tell: vertex count is lower than the known population because V was derived from the edgelist alone.
• Relying on a drawing to validate the graph. The tell: the diagram looks plausible, but nobody has checked the edgelist, edge count or edge properties against the source data.

• ▸Analytic question: one sentence stating what you want to learn.
• ▸Vertex entity type(s): what each vertex represents, and whether there is more than one type.
• ▸Vertex set source: where V comes from, and whether isolates are included or ignored.
• ▸Edge rule: an if-and-only-if sentence defining when two vertices are connected.
• ▸Direction: undirected or directed, with a note on which column is 'from' and which is 'to'.
• ▸Multiple relationships: single type, or multigraph with an edge-type property (list the types).
• ▸Edge weight: none, or what it counts or measures and how it is calculated.
• ▸Loops and duplicates: allowed or not, and how they are checked.
• ▸Validation check: expected vertex and edge counts versus the counts regenerated from the built graph.

1. 1State the inference before you open a plotting library. Write one sentence: 'The viewer should conclude ___.' The source ties graph work to four kinds of question: connection, information flow, community/diversity/familiarity, and importance/influence/attachment. Each needs a different visual emphasis, so pick one.
2. 2Fix what a vertex and an edge are, and what each edge means, before styling. The book treats this as a data step (edgelist, adjacency matrix, or dataframe, then vertex and edge properties). Example: two salespeople are linked if they served the same customer in the same month. Write the edge definition on the figure.
3. 3Compute the property you want to show before you plot, then attach it to the graph as a vertex or edge property. The source's measures are degree, closeness, betweenness and eigenvector centrality for importance, and components, partitions, communities and cliques for structure. A visual channel can only encode a property that already exists on the object.
4. 4Map one property to one channel. Importance (centrality) goes to vertex size. Community or partition membership goes to vertex color. Edge weight or strength, if you have it, goes to edge thickness. Never use size and color for the same property, and never use one channel for two properties.
5. 5Choose the layout algorithm for the question. Chapter 3 treats layouts as a separate decision from styling (igraph layouts). Run at least two layouts on the same graph and keep the one where the structure you named in step 1 is visible without explanation. Fix the random seed so the figure is reproducible.
6. 6Choose the medium by audience. The book covers static plotting (igraph, ggraph, networkx with matplotlib) and interactive plotting (visNetwork, networkD3, pyvis). Use static for a report or slide that must make one point. Use interactive when the audience must explore a large graph and look up individuals.
7. 7Test the figure. Show it to someone who has not seen your sentence from step 1 and ask what they conclude. If their answer differs, change the encoding or layout, not the caption.
8. 8Add a legend and a one-line statement of the edge definition and the measure used. Without them, vertex size and color are not interpretable.

The source's setup is a sales organization where you want to know whether two salespeople are connected through serving the same customer in the same month. Rectangular sales and customer tables are joined, then re-joined, to produce a salesperson-to-salesperson edgelist. The inference you want is who the connectors are and which pockets of salespeople cluster together. First attach two properties to the vertices: a centrality score (degree or betweenness) and a community label from a community detection algorithm. Plot with ggraph. Map centrality to vertex size and community to vertex color. Try a force-directed style layout against others and keep the one that separates the communities. Label only the few largest vertices, since the source's 'superconnectors' use case is about finding those people. The caption reads: 'An edge means two salespeople served the same customer in the same month. Size is betweenness. Color is community.' This is an illustration of the workflow. The source lists these tools and measures but does not give this figure's output.

• If the question is who matters, then compute a centrality measure, map it to vertex size, and label only the top vertices.
• If the question is who groups with whom, then run community detection or partitioning, map membership to color, and choose a layout that visibly separates the groups.
• If the graph is disconnected, then check connected components first. Color or lay out components separately so isolated pieces are not read as weak ties.
• If the audience needs to look up individuals or explore a large network, then use interactive tools (visNetwork, networkD3, pyvis). If you need one fixed message, then use a static ggraph or networkx figure.
• If two layouts tell different stories about the same data, then trust the computed measure, not the picture, and choose the layout that shows the measure faithfully.

• Hairball: every vertex is the same size and color and all edges are drawn, so nothing stands out. The tell is that viewers cannot say what the figure shows.
• Styling before computing: size or color is assigned to an arbitrary attribute rather than a calculated measure. The tell is that you cannot name the measure behind the biggest vertex.
• Reading layout position as meaning: closeness on the page is mistaken for closeness in the network. The tell is that rerunning the layout with another seed changes the claimed story.
• Undefined edges: the audience does not know what a connection means (same customer, same month, communication). The tell is that people ask 'connected how?'.
• Using the wrong medium: an interactive tool for a one-point slide, or a static image for a large graph that must be explored. The tell is that the presenter has to narrate or zoom to make the point.

• ▸Intended inference: one sentence completing 'The viewer should conclude ___'.
• ▸Audience and medium: who sees it, and whether it is static (igraph, ggraph, networkx) or interactive (visNetwork, networkD3, pyvis).
• ▸Vertex definition: what each vertex represents.
• ▸Edge definition: what an edge means, and whether it is directed or weighted.
• ▸Property for vertex size: the centrality measure (degree, closeness, betweenness or eigenvector) and why.
• ▸Property for vertex color: community, partition or component label, and the algorithm used.
• ▸Property for edge thickness: weight or strength, or 'none'.
• ▸Layout algorithm and seed: layouts tried and the one chosen, with the reason.
• ▸Labeling and legend text: which vertices are labeled, plus the one-line caption stating the edge definition and the measures.

1. 1Fix what an edge means before counting anything. In Euler's proof, places were vertices and bridges were edges. In an organization, decide whether an edge is a collaboration, a message, or a friendship. Degree only means 'reach' relative to that definition.
2. 2Build the edge list as one row per connection, then load it into a graph object. The book's practice case is the koenigsberg data set (https://ona-book.org/data/koenigsberg.csv, also in the onadata package).
3. 3In R, run igraph::degree() on the igraph object. It returns a vector with one degree per vertex. Name the vector by vertex and sort it descending.
4. 4Sanity-check the vector. Each edge touches two vertices, so the degrees must sum to twice the edge count. Seven bridges should give a total of 14.
5. 5Count the vertices with odd degree. Euler showed that an Euler walk can exist only if that count is 0 or 2. In R, the eulerian package's hasEulerianPath() tests the same question.
6. 6Read the top of the sorted vector as 'most immediately connected', not 'most important overall'. Degree is local. The book lists closeness, betweenness and eigenvector centrality (chapter 6) as separate measures for other kinds of importance.
7. 7Plot or tabulate the whole degree distribution, not only the leaders. Check whether a few vertices hold most of the connections. Do not assume a power law, because recent research (Broido & Clauset 2019; Fisher et al. 2017) finds social networks are at best weakly scale-free.
8. 8Report the degree values together with the edge definition and the data source. This lets a reader see what 'connected' meant.

Königsberg has four land masses (vertices) and seven bridges (edges). Euler reasoned that a walk crossing all seven bridges once makes eight place visits, because the start counts as one visit and each bridge crossed adds another. A place with an odd number n of bridges is visited (n+1)/2 times. Three of the places have three bridges each, so each is visited twice. The fourth is visited three times, which corresponds to five bridges. The visits total 3 + 2 + 2 + 2 = 9, not 8, so no such walk exists. In degree terms, the degrees are 5, 3, 3 and 3, which sum to 14, twice the seven bridges. Four vertices have odd degree, and Euler's rule allows only 0 or 2. In R, igraph::degree() on the koenigsberg data returns this vector directly.

• If the degree vector does not sum to twice the edge count, then check for duplicated rows, self-loops or missing vertices before interpreting anything.
• If you need to know whether a route can use every edge exactly once, then count the odd-degree vertices. Anything other than 0 or 2 rules the route out.
• If two vertices tie on degree but you must choose between them, then compute closeness, betweenness or eigenvector centrality. Degree sees only immediate links.
• If the degree distribution has a long tail, then describe the tail as observed. Do not label the network scale-free without evidence, since the literature says social networks rarely are.
• If you present a highly connected person as an 'influencer', then state that this rests on immediate connections and on how you defined an edge.

• Treating degree as overall influence. The tell is a ranking that ignores who the neighbors are or where the vertex sits in the network.
• Leaving the edge definition vague. The tell is two analysts getting different degrees from the same organization and no one able to explain the gap.
• Skipping the sum check. The tell is a total degree that is odd, or does not equal twice the edge count, which signals data-entry errors.
• Assuming preferential attachment or a power law from a few high-degree vertices. The tell is the words 'scale-free' or 'Matthew Effect' appearing without any distribution analysis.
• Misreading the odd-degree rule. The tell is claiming an Euler walk exists because most vertices have even degree, when the count of odd-degree vertices is not 0 or 2.

• ▸Edge definition: state in one line what a connection (edge) means in this data.
• ▸Vertex count and edge count: record both numbers from the loaded graph.
• ▸Degree sum check: write the sum of all degrees and confirm it equals 2 × edge count.
• ▸Top 5 vertices by degree: list name and degree value, sorted descending.
• ▸Odd-degree vertex count: record the number, and whether it is 0, 2 or other.
• ▸Degree distribution note: describe whether a few vertices hold most connections or degrees are evenly spread.
• ▸Complementary measure: name which of closeness, betweenness or eigenvector centrality you will check next and why.
• ▸Caveats: list data gaps, ties, and any claim you are NOT making, such as scale-free or influence.

1. 1Confirm the graph is connected before you compute anything. The source defines closeness centrality for a vertex 𝑣 in a connected graph. If any vertex is unreachable, distance is undefined (the diameter is infinite), so restrict the analysis to a connected subgraph.
2. 2Decide whether edges carry weights. The source notes that centrality is usually computed unweighted. If you do use weights, transform them into cost functions (for example by inverting them) so that higher-weight edges count as preferable in traversal. Then compare the shortest paths under summed weights and under summed inverse weights.
3. 3For vertex 𝑣, find the shortest-path distance to every other vertex. Group the other vertices by distance (1, 2, 3, …) so you can check the count against |V| − 1.
4. 4Sum the distances. Multiply each distance by the number of vertices at that distance, then add the products.
5. 5Invert the sum: closeness = 1 / (sum of distances). A lower total distance gives a higher closeness, so the highest-closeness vertex reaches everyone most efficiently.
6. 6In R, use igraph's closeness() function for all vertices or a subset. Check the result against one hand-calculated vertex first (Vertex 8 in G14, closeness 0.038) so you know the function's output matches the definition you intend.
7. 7Compare across vertices on the same graph only. Rank the vertices and read the top ones as the fastest potential spreaders of information.
8. 8Read the result alongside degree, betweenness and eigenvector centrality. The source stresses that centrality means different things depending on how you define it, so check whether closeness picks out the same people as the other measures.

The source's example is Vertex 8 in the 14-vertex connected graph G14. Vertex 8 is at distance 1 from vertices 4, 7 and 9 (3 vertices). It is at distance 2 from vertices 1, 2, 3, 5, 6, 10 and 13 (7 vertices). It is at distance 3 from vertices 11, 12 and 14 (3 vertices). That accounts for all 13 other vertices. The sum is 3×1 + 7×2 + 3×3 = 3 + 14 + 9 = 26, and the inverse is 1/26 ≈ 0.038. Vertex 7 has a slightly lower total distance of 25, because its extra direct edge to Vertex 6 shortens a path. Its closeness is therefore 1/25 = 0.04. One edge changes the ranking, even though both vertices are among the highest in the graph. In an organizational network, information shared by someone like Vertex 7 would likely reach the whole network slightly more efficiently than information shared by Vertex 8.

• If the graph is not connected, then compute closeness within each connected component or subgraph. Do not compare against vertices in other components, because the full-graph distance is infinite.
• If your question is how quickly information spreads from a person, then use closeness. If it is how many people someone knows directly, use degree centrality (ego size at order 1 is degree + 1).
• If two vertices have near-identical closeness (0.038 vs 0.04), then treat them as roughly equal. Check the underlying distance sums before declaring a winner.
• If edges carry weights, then convert them to costs (for example by inverting) before computing distances. Otherwise high-strength ties will read as long distances.
• If closeness and degree rankings disagree, then report both. The source says the different centralities imply different roles, so a disagreement is a finding, not an error.

• Applying closeness to a disconnected graph. The tell is infinite distances, or results that are meaningless or suspicious for some vertices.
• Reading high closeness as many connections. The tell is that a low-degree vertex scores well because it sits near the middle of the network; closeness measures total distance, not neighbor count.
• Treating the raw value as an absolute score. The tell is that you compare 0.04 across different graphs; the value depends on the graph's size and structure, so compare within one graph.
• Feeding weights in unchanged. The tell is that strongly tied pairs appear far apart, because larger weights are being summed as larger distances.
• Skipping a hand check. The tell is a function output you cannot reproduce for any single vertex, which suggests the wrong graph type (directed vs undirected) or edge list was loaded.

• ▸Graph name and connected? (Y/N): confirm every vertex can reach every other; if N, name the subgraph used.
• ▸Vertex analyzed: the vertex 𝑣 whose closeness you compute.
• ▸Weights used? (none / inverted cost): state how edge weights are handled.
• ▸Count at distance 1: number of vertices exactly one edge away.
• ▸Count at distance 2: number of vertices exactly two edges away.
• ▸Count at distance 3+ (list each distance): continue until all other vertices are accounted for; the counts must total |V| − 1.
• ▸Sum of distances: add distance × count for each row.
• ▸Closeness (1 / sum): invert the sum and round to three decimals.
• ▸Comparison to degree, betweenness, eigenvector: note whether the vertex ranks similarly, and what any difference implies about its role.

1. 1Fix the graph before you score anything. State what an edge means (email, calendar, timesheet, document collaboration) and whether it is directed or weighted. Different connection definitions can produce substantially different networks, so a betweenness score only means something relative to the edge definition.
2. 2Write the definition down as the calculation. For a vertex v, take every pair of OTHER vertices x and y. Count the shortest paths between x and y, and count how many of those pass through v. Divide the second count by the first, then sum that fraction over all pairs.
3. 3Sort pairs into zero-contribution groups first, so you only do arithmetic where v can matter. A pair contributes nothing if v is not on any shortest path between them. This happens when the two are adjacent, or when a shorter route avoids v.
4. 4For the remaining pairs, enumerate the shortest paths between x and y only. Longer routes are ignored. Record the fraction (paths through v) / (all shortest paths). A single bridge scores 1 for the pair. Two equal routes with v on one score 1/2.
5. 5Sum the fractions to get v's betweenness. Check the result by hand on a small subgraph before trusting software output on the full graph.
6. 6Run the library calculation in R or Python and confirm it matches your hand figure on the small case. Then compute degree, closeness and eigenvector centrality on the same graph. The karate-club exercise (the karate data set in the onadata package) is a good place to practise.
7. 7Compare the rankings side by side. A vertex that ranks high on betweenness but not on degree is a bridge or 'superconnector'. A vertex that ranks high on closeness but low on betweenness is efficient at reaching others but is not a gatekeeper, because other vertices can route around it.
8. 8Illustrate the scores in a graph visualization (for example, vertex size mapped to betweenness) and check that the high-scoring vertices sit between clusters rather than inside them. Then state the claim in terms of shortest-path routing, not general 'influence'.

The source's 14-vertex graph G has Vertices 7 and 8 as the focus. To compute the betweenness of Vertex 8, you test every pair of other vertices. Pairs within Vertices 9–14 contribute 0, and so do pairs within Vertices 1–7. Vertex 7 to Vertices 9–14 contributes 0 because Vertices 7 and 9 are adjacent, so Vertex 8 is not on a shortest path. Vertex 6 to Vertices 9–14 contributes 0 because the shorter route runs through Vertex 7. The only pairs that matter are Vertices 1–5 against Vertices 9–14, which gives 5 × 6 = 30 pairs. Each of those pairs has two shortest paths, one through Vertex 7 and one through Vertex 8, so each contributes 1/2 for Vertex 8. By the definition, the total is 30 × 1/2 = 15. Vertex 7 earns the same 15 from those pairs, so the two vertices split the bridging role. The same graph shows why closeness differs: Vertex 7 has a slightly higher closeness (total distance 25, closeness 0.04) because of its extra direct edge to Vertex 6, even though Vertex 8 also has one of the highest closeness scores.

• If you need the person or tie whose loss would most disrupt connectivity, rank by betweenness. If you need who can spread a message fastest to everyone, rank by closeness instead.
• If two vertices bridge the same pair groups by parallel equal-length routes (as Vertices 7 and 8 do), treat them as sharing the bridge role. Each earns a fraction per pair, so neither is a single point of failure for those pairs.
• If a vertex's score comes from few pairs with high fractions, it is a true bridge. If it comes from many pairs with small fractions, it sits in a redundant region, so avoid calling it a gatekeeper.
• If degree and betweenness rankings disagree, report both and name the role each implies (popular versus bridging). Do not collapse them into one 'influence' rank.
• If the edge definition changes (email versus calendar, say), recompute the scores and do not assume the same superconnectors persist.

• Counting all shortest paths through v instead of the fraction. The tell: a vertex like 8 scores 30 when it should score 15, because you ignored the parallel route through Vertex 7.
• Including v as an endpoint of the pairs. The definition uses pairs of OTHER vertices. The tell: your pair count includes pairs that start or end at v.
• Crediting v for pairs where it is not on any shortest path. The tell: you counted Vertex 6 to Vertices 9–14 through Vertex 8, missing that the route through Vertex 7 is shorter, or you counted Vertex 7 to Vertex 9 despite their being adjacent.
• Treating high degree or high closeness as proof of bridging. Vertex 8 has among the highest closeness in G, yet its betweenness comes only from one block of pairs. The tell: you never ran the other centralities for comparison.
• Reading betweenness as influence in general, or assuming preferential-attachment structure. The source notes social networks are at best weakly scale-free, and different centralities imply different roles. The tell: your conclusion says 'most influential' with no path-based reasoning behind it.

• ▸Edge definition: state what a tie means (email, calendar, collaboration, etc.) and whether it is weighted or directed.
• ▸Vertex under test (v): name the vertex being scored.
• ▸Zero-contribution pair groups: list the groups where v is on no shortest path, and why (adjacent pair, shorter route elsewhere, v not between).
• ▸Contributing pair groups: list the groups of pairs where v lies on at least one shortest path, with the pair count for each.
• ▸Fraction per pair: for each group, write (shortest paths through v) / (all shortest paths).
• ▸Betweenness total: sum of pair count × fraction across groups, and confirm it matches the software output.
• ▸Comparison ranks: v's rank on degree, closeness, betweenness and eigenvector centrality.
• ▸Role interpretation: name v as bridge/superconnector, popular hub, efficient spreader or none, based on the rank pattern.
• ▸Redundancy check: list the other vertices sharing v's bridging routes and what happens to those pairs if v is removed.