Wiki stores numbers in json and shares them through http requests. We see a lot of variety in how numbers get into json and what happens to them after they are fetched. This makes Federated Wiki less like the world's largest single content repository, (Wikipedia 
]), and more like Excel.
Server Side
Servers are free to rewrite the json they store and might do so to track streaming data. See Air Temperature.
When one forks a page from a server-side stream the connection to that stream is (appropriately) broken.
High resolution or frequently updated data should carry its own timestamps independent of those in the journal.
Servers might create whole pages when they update data. One would expect the journal to reflect only the most recent creation. It is possible to keep older versions by preserving a series of create actions.
Servers might find and update specific items within a page. In this case the journal reflects only the manual configuration of the items on the page, not the automatic updating of data within a particular item.
Servers can offer live, two-way, low-latency connectivity specific to specialized plugins. See About Txtzyme Plugin.
Client Side
Clients fetch and render json using a repertoire of plugins to interpret, transform and visualize data. Wiki retrieves and launches plugins for each item it renders.
Plugins are free to cooperate with other plugins they discover by exploring the DOM. By convention they look to their left when retrieving data so one experience data flowing from left to right. See About Method Plugin.
Plugins may recognize useful items by their type. Items display their type as a class attribute when rendered in the DOM. This approach breaks down as item types proliferate.
Plugins may recognize useful items by semantically meaningful class attributes added to the DOM by the item's plugin. The sourcing plugin can further annotate the DOM with access functions to be called by the downstream plugin at will. See About Radar Plugin.
# expose access to "radar" format data div.addClass 'radar-source' div.get(0).radarData = -> output
Plugins may look for data in several formats. Our first experiment with d3.js (D3 Line) expected to find a Chart Plugin with time sequence data. This was later generalized to look for plugins advertising sequence-source which respond to getSequence(). See About Txtzyme Plugin which collects data from remote devices and reports the sequence.
Plugins are free to fetch json for pages not found in the DOM. It is possible for a plugin to instantiate a slave plugin for the purpose of interpreting the otherwise inert json they might fetch. See About Rollup Plugin which uses a slave Method plugin to repeat calculations.
A plugin that expects to be used as a slave must offer some special access to its capability. For example, the Method plugin offers a complex eval interface including callback when evaluation is complete.
# evaluate item with input calling back with output eval: (caller, item, input, done) -> state = {caller, item, input, output: {}} dispatch state, (state, input) -> done state.caller, state.output
Plugins are free to trigger and handle events so as to cooperatively respond to changing situations such as additional user input.
Many plugins signal and/or respond to the thumb event indicating a new position of the user's thumb when scrubbing through a dataset. By convention thumb notifications flow both left and right so users are free to scrub coordinated data from where ever convenient. See About Data Plugin.
Variables
A runtime data representation has emerged between the plugins we have already mentioned.
longish variable names in title case
values that we think of as numbers but may be strings or value objects
inputs merged, output only changes