Now, there is another important notion which we need to define. A reference table is:

a physical table which has a table number which is known

For example, the table to the right-hand side of the front door is a reference table for me. Note how this is a subjective concept: it is a reference table for me. This is because I can remember that it is Table 10. I do not have to check the map each time.

What is a reference table for me might not be a reference table for somebody else. Perhaps my colleague does not remember where Table 10 is. Instead, they remember where Table 9 is. Perhaps this person counts from 9 (the table they know) over to Table 10. This is in the same way that I would work out the table number 9 by using Table 10 as my starting point.

What is the relationship between reference tables and streams? Streams are a beneficial device. They mean that instead of associating the numbers 1-6 with six distinct chunks of wooden furniture, I can just commit one reference table to memory. Then, I can use this reference table to count to the other tables.

Streams impose a conceptual framework onto the tables, making sense of them. Kant famously said

"intuitions without concepts are blind".

To avoid blindness we brandish the tables with streams.

But just because all the tables form streams, some problems still remain. Let me list some of them. First, I might forget which table numbers actually make up a stream. The number which starts off a stream can seem arbitrary, and this can cause me to forget which numbers make up the stream. Here's an example. I know that at the back of the pub, all the tables along the left wall form one stream. I can point to the first table in the stream and the last table in the stream correctly. I can also tell you how many tables are the stream. However, I cannot remember that Table 24 is where the stream begins. I often think the stream begins with Table 23, and on some days I think it begins with Table 25. Because of this, I lose grip of my knowledge of all the table numbers in the screen.

Here is a second problem which still exists when all the tables form streams. I might forget which stream a table is part of. Perhaps there are different ways of "carving up" the room of table, each way just as valid as the other. The final configuration of streams can seem arbitrary sometimes.

A third problem is that I might forget how many tables make up a stream. If this is the case, then there are certain situations when the stream becomes useless to me.

So, there are three problems which still remain when all the tables sit in streams. The full quotation from Kant is "thoughts without content are empty, intutions without concepts are blind". You can be plagued by emptiness - you can keep forgetting how to fill out the conceptual streams with the real, rotting chunks of wood.

The value of knowledge

It's worth asking: what is the value of knowledge of a table number? We can distinguish a few different situations.

Situation 1- a customer comes to the till and orders food. They say "I am sat there" and point to their table.

In this situation, knowledge of table numbers allow the cashier to associate the table being pointed at with a number.

Situation 2 - a waiter has a food ticket for Table 14.

Knowledge of Table 14's location would be useful here. But it is not necessary because a map can be checked.

Situation 3 - a customer comes to the till and orders food. They say "I'm sat at the back at a table". Given that they cannot point to their table, because it is not visible, they do not do this.

Instead, they go and get their table number and come back. Obviously, in the situation, employees having knowledge of table numbers is useless.

Situation 4 - a customer comes to the till and orders food. They say "I do not know which table number I am sat at" but they then attempt to describe, using words, the location of their table.

This Situation is the most interesting. What can possibly happen in Situation 4? First, the cashier might ask the customer to go and retrieve their table number. Second, the cashier might be able to make use of the verbal description to identify the table number exactly.

Let's examine these possibilities. Asking the customer to retrieve their table number can be problematic. This is because it may come across as rude. It is a burden for the customer to walk away and come back (even if customers sometimes voluntarily begin doing this, believing it to be necessary). Sometimes it is unnecessary: the pub is almost empty, and the person delivering the food will be able to recognise the person who paid for it at the till. Furthermore, if the food goes to the correct general area, then the correct guest can be worked out quite easily.

Now, it is unlikely that the verbal description is good enough to identify the table number exactly. The guest would have to be extraordinarily articulate at describing the architecture of the pub, perhaps picking out features of each wall and recalling whether the table was the fifth table in or the fourth table in.

Usually, a third possible situation occurs. The guest provides a verbal description. It allows the cashier to identify a region of the pub. The description lacks the precision required for the cashier to deduce the exact table number. But it does allow the cashier to associate the guest with a particular region of the pub. For example, the guest will successfully convey that they are in the back garden. Or they might convey that they are on one of the tables which is indoors, and near the back garden.

In this situation, the cashier must still select a table number. The till software requires it. Therefore, they probably pick any table number which they know to be in the region specified. We'll call these sorts of situations, where the cashier is really using a table number to denote a region, and not necessarily a particular table, region ascription. The cashier ascribes the customer to a region.

We might talk about there being a set of guest phenomena. In this context, a guest phenomenon is a feature of the pub which the guest pays attention to, in order to communicate their table location to the cashier.

A cashier, in eliciting the table number from the guest, must draw on this set of guest-phenomena. The cashier could refer to features which the guest is not aware of (for example, "the picture of Thomas Doggett on the wall" or "the third table in"). If he does this, he will fail to communciate. The guest doesn't know whether he's the fourth or third table in. He doesn't care what Thomas Doggett looks like. So, you must draw on guest-phenomena. Examples include "to the right of the front door of the pub" or "the table which is a ledge" or "the table outside the back".

The same thing occurs with wines. Employees cannot mention specific brands such as Rothschild or Coastal Reserve or Oyster Bay, and expect this to have meaning for guests. The employee is familiar with these concepts but the guest is not. They need to use guest phenomena: white wine, red wine, sauvignon blanc, chardonnary. Excellent employees know how to properly map the guest phenomena to the concepts which they have knowledge of (Oyster Bay, Rothschild, sweet, dry, etc.)

"The problem, I say, is the shoulders. But the customer says "no". He likes the shoulders. "The problem is the sleeves. It's my money, and I'm telling you, Cut the sleeves". I say "yes sir" and then I cut the shoulders. The customer comes back, tries on his suit. "It's perfect" he says. "That's exactly what I asked for"

The Outfit (2022)

Straightaway, we can note that some of the categories which make up the set of guest-phenomena lack the required resolving power. An example is "the table outide the back" There are many tables outside the back, so this category is true of the table, but not precise enough. We're just noting this fact, as we work towards a solution.

Region Ascription

The conclusion which we can draw from above is that in certain situations (Situation 4), all a cashier will ever do is ascribe a customer to a region. Now that we are clear that this happens, I think it would be beneficial if servers (those delivering the food) had a way of knowing whether the table number assigned to a guest is a table-ascription or a region-ascription. In other words, I'm asking whether these is a way to communicate to a colleague: "This table number is likely to be incorrect. It's really a region ascription"

One solution is to have one designated table in each region. We assign guests to this table whenever we do not know their precise table . If the person delivering the food understands the table number is a Region designator, then they can pre-emptively seek out the information required to deliver the food to the correct guest.

The Region designator could be the first number in each stream. So it works as follows. Table 70 basically means "outside". Table 120 basically means "in the stream which starts with Table 120". Table 130 basically means "in the stream which starts with Table 130".

In fact, the set of Region designator tables can be the set of refernce tables. But of course, for this to work, we would need an objective set of reference tables.

Is flow beneficial?

Most people would say that it is beneficial if table numbers flow. If there is a large pub, then it is a good thing if there is a route around the tables. As you move along the route, the numbers move upwards. The physical parts fit together in the same way that the abstract numbers fit together. Just as 7 is close to 8, Table 7 is physically close to Table 8.

But is it always beneficial for tables to flow in this way? Engineers and scientists have devoted thousands of hours to creating smooth roads. Tarmacs have had their chemical composition adjusted and refined. Theories have been devised about how to layer the materials on the road surface. This ensures that it is, for example, quiet when driving along a motorway.

And yet, despite this illustrious history of striving towards superior smoothness, councils spend thousands of pounds intentionally installing bumps in roads. In somes roads leading to a roundabout rumble strips are created to literally "wake up" drivers. To a Martian, observing humans on earth, this intentional destruction of the smoothness would be inexplicable.

Rumble strips remove the flow which the road provides. These bumps in the road are incredibly useful, because they are safety devices. The vibrations of the humble rumble alert the driver that he is veering off the road and about to violently end four lives. The bumps are knowledge devices: the bumps in the road ensure a driver knows that [he is veering off the road].

This means that there is something unusual which we are forced to accept: By removing flow, we can provide knowledge.

So, are there situations in which the removal of flow in a pub can provide knowledge? I think there are. Often, you feel that you want to explain why a particular chunk of wood has a particular table number. The explanation may take the form of stream membership. "This table is Table 3 because it is part of this stream of tables" runs the explanation.

However, if we step back for a moment, we might recall that our aim is not necessarily the ability to explain each table number. Strictly speaking, we are not trying to explain why this chunk of wood is Table 24 in the way that scientists strive to explain how cancer works.

Our aim is to provide guests with a satisfactory experience. Our aim is to ensure that food is brought to the correct guest. I suspect we achieve this by establishing procedures. These procedures ensure good communication amongst employees. And perhaps it is helpful to remember certain reference tables, or use a table map. Anyhow, our aim is not to explain table numbers, as such.

If table numbers form a stream, then there's a sense in which you can get lost in the flow. You can explain each table number, certainly, but consider that you haven't made it easier to identify where you are, when you are sat at one table in the set. You haven't made it easier for somebody who comes up the bar to say which table they were sat at. Maybe you weren't trying to achieve that anyhow. But, then, it is worth asking: What have you achieved?

You may have made certain tables harder to refer to, by making them part of a stream. If we reflect upon what a stream is, we can think of it as an explanatory ecosystem. Tables at the bottom explain the tables at the top. The tables at the top recieve their explanations from the tables lower down. For example, if there are Tables 1 to 5, we can say that table 1 helps to explain Table 2. For example: "I know this is Table 2, because it's next to Table 1." Table 2 might be invoked to explain why Table 3 is Table 3, and so on. The tables are related to one another in various ways. When all works well, this means that, overall, each individual table is slightly easier to identify than without the stream.

But this might be unfortunate. With a stream, we gain the habit of relating the tables to each other. We come to depend on these relational properties, the way an alcoholic depends on alcohol. We reach for them instinctually when trying to ascribe a table number to a table . Yet the relations are very arbitrary. One table starts to be conceived as "the sixth table in the stream". If the table is "the start of the stream" then this is intersting and memorable. But to be nothing but "the sixth table in the stream" is just the concept of six. The "sixth table in the stream" is similar to "the seventh table in the stream". This makes the ability to name the tables identical with the ability to count. A useless achievement! Since there are diffent ways to count the tables in the room and "carve up" the tables, and organize them into streams, being able to count along the tables doesn't actually have anything to do with our ability to identify individual tables in the pub.

The "Collapse" argument against streams

Like a balloon which can burst if inflated too much, a stream can be stretched too far. Once we know that a table is part of a stream, when trying to think what Table number it is, we reach for its neighbour. But let's suppose that we do not know its neighbour's number; we only that the neighbour is part of a stream. We reach for its neighbour. And so on, and so on. The might continue until we reach Table 1. Or we might just get lost.

The point is that sorting tables into streams can result in a sort of collapse, or hollowing out. It would be absurd to, say, know the location of Table 1 and count up through 37 tables, in order to estbalish that one table is Table 37. Each table is plumbed into the other. But if the one fails, then its neighbours fail. It is like christmas lights on a string, which are connected in series, such that if one fails they all fail. It is similar to a bubble, such as the "dot com bubble", bursting.

It's in this way that it is possible to make tables harder to refer to by making them part of a stream. If the stream is sufficiently large, then it becomes possible to get lost in the stream. The mind preferentially goes to relational properties which the table has, over its intrinsic properties. You're purely reasoning about tables. This leads to a collapse phenomenon.

De-coupling Streams

To avoid a "Collapse" phenomenon while using streams, we should make them loosely coupled. To make them loosely coupled, we reduce the extent to which one is dependent on the other.

We encourage the map viewer to relate particular reference tables to their actual position--to their location--and not to other tables. "Table 10 is to the right of the door" and not "Table 10 is next to Table 9".

Now, we don't want to do this with all the tables; we want to retain the benefit of streams. Recall that streams allow us to deduce table numbers, and not have to remember each individual table numbers in the pub. But we do want to encourage the map-viewer to associate a few tables with real, physical locations in the pub. We want the map to discourage the viewer from purely associating tables with each other.

But how do we achieve that? The answer is that (counterintuitively) we make the map less informative than it could be. We intentionally make the map so that it does not display all table numbers. I will call this concept an Abbreviated Map. All we display are the streams, represented using arrows, and one reference table to begin each stream.

The reason this is beneficial is, firstly, that it forces people viewing the map to realize that tables are organized into streams. They cannot simply find the one table number that they are interested in. We actually dig out table numbers from the map, the way labourers dig out chunks of road in order to create rumble strips.

Secondly, we are decreasing the extent to which reference tables are subjective. Recall that Table 10 might be a reference table for me, and not for my colleague. We develop different reference tables because we had particular experiences on one table, or because of other arbitrary factors. So, let me explain how an Abbreviated Map decreases the subjectivity from reference tables. (Or rather encourages a set of colleagues to develop the same, subjective set of reference tables.) Every time somebody looks at the map, it is because of ignorance (of some fact). When they view the map, there a lots of things they may learn. By limiting the map to a subset of the table numbers, we focus what is learned on each viewing.

To explain this idea about focussing, consider a map which simply displays every single table number. Over the course of an hour, delivering food to tables 3, 4, and 5, the server might think about each of these table numbers individually. But with an abbreviated map, the same fact is used for each of these deliveries. In each case, the map says "Here is Table 1". And the server uses this fact in each of the three situations. He counts from 1 to Table 3. He counts from 1 to Table 4. He counts from 1 to Table 5. This means that he has contemplated the physical location of Table 1 three times over the course of an hour. This makes it possible for the server to associate this table with the physical location in the pub. And that was what we were trying to achieve. We wanted to plug in a subset of table numbers into the physical architecture of the pub.

By doing this, the map encourages all servers to develop the same set of reference tables. By encouraing particular table numbers to be learned, we discourage thinking of tables in purely relative terms, and so discourage Collapses.

Representing Streams

There are good ways and bad ways to represent streams on a map. A bad way of representing a stream is to use an arrow conisting of a line with a head (triangle) at one end. This is bad because if you place one table number over the head, the directionality of the stream is completely lost. A better way is by using chevrons. The "line" is in fact a series of arrow-heads, stacked together. It is very thick - much thicker than the movable tables.

A bad way of representing a stream is to use arrows all the same colour. A good way to represent streams is to use different colours for each stream. This makes it easier to distinguish streams.

The righthand map conveys the directionality faintly. The lefthand map produces a vivid impression of the directionality.

Perhaps the table number is meant to be the explanation for something, and not the thing which we should be seeking to explain. An explanation for what? Well, for the location of the guest. In this way, we flip everything on its head. We embrace the idea that certain table numbers cannot be explained by their neighbours.

What we cannot explain is more memorable than what we can explain. "Why is Table 36 over here?" I joke with my colleague, exasperated. But really, the game is won. If I'm confused by Table 36 and its location, then I know its location. If I love the location of Table 36, then I know its location. If I hate the location of Table 36, then I know its location. In all these cases, the architect of the table numbers has won. If you think of it, it is. By avoiding flow, we can sometimes achieve better effects than embracing perfect flow.

Important skills

What is rapport?

What makes a table map excellent?

Some observations