ha-sitehub-Q&A.md

 ## Sitehub Details : 
 The Sitehub House Ads architecture is approximately as seen here:
 
-<Attach Sitehub Block diagram>
+*See alex for diagram*
 
 Technologies used:
 Nitrite for the database, mostly for it's document database approach.
@@ -18,11 +18,45 @@ Downloading uses ID as a key and the HASH in compositions and assets is what dri
 ## Re: block-diagram
 The block diagram as present doesn't match what i would expect for the server layer.
 
-The front end has a set of calls it makes to Mystery Machine APIs. Mystery Machine verifies permissions and then makes a call to the get_stored_procedure API in cheerios. Please let me know if this is not understood and I can make corrections if sent a file or i can rediagram it.
+The front end has a set of calls it makes to Mystery Machine APIs. Mystery Machine verifies permissions and then makes a call to the get_stored_procedure API in cheerios. Please let me know if this is not understood and I can make corrections if sent a file or i can rediagram it. If you want to know HOW houseads physically chooses, composes, or displays an ad, this aint it.
 
+## Ad Play Logic
+
+HouseAds App may be dormant or stopped/dead entirely to start. It has two categories of processes, asynchronus background tasks and display related tasks. There is no presupposition as to what will happen in what order. If no background tasks have run, houseads can still run. It will just have nothing to play off of.
+
+1.  Spectator receives an ADBREAK type message, passes on to AdPresenter (within Spectator)
+2.  AdPresenter PREPAREs and PLAYs one vistar ad. When the vistar begins the PLAY, AdPresenter PREPAREs houseads.
+3.  When vistar ad is PLAYBACK_COMPLETE AdPresenter sends PLAY to houseads and waits *15 seconds*.
+4.  After 15 seconds, AdPresenter sends a STOP to HouseAds. AdPresenter will PREPARE and PLAY vistar ads.
+5.  when vistar ad is PLAYBACK_COMPLETE, AdPresenter will PREPARE and PLAY ads.
+6.  step 5 repeats until time is up.
+
+If HouseAds receives a PLAY with no PREPARE it will complete all the same work and just expect to be late. This is why the STOP message is important. Houseads functions only through one-way intents currently, although this is not architecturally required. Since houseads has no way to communicate back, it should be able to begin with any state and successfully complete its process. This ALSO means that a state of PREPARE->invalid must be handled and should still remain at a 100% success rate. Hence the requirement for fallback ads.
+
+Conditions where "Fallback Ad" is played:
+* There is no ad scheduled that matches play criteria (Start date < today < end date,  Weekdays includes today)
+* Local database is corrupt
+* Local database is inconsistent/incomplete
+* Expected Files are missing on local storage
+* Expected Files are download are incomplete
+
+The philosophy here is that we are responsible for filling a slot. Since there is no way (and no requirement) to hand that time back to vistar, we need to fill that space. If we don't, it will play whatever the AdPresenter in Supervisor is displaying. It is likely the last frame of the last ad. think of it as "ANY reason we did not have a **valid and present** housead to play, a fallback ad will play.
+
+Fallback ads **must** meet certain requirements:
+1. require NO runtime-combining, single file composition.
+2. be gaurenteed
+3. be unattached to a schedule
+
+If these are not met it will lead to pain and suffering. 
+
+No runtime-combining: Reduce code path to playing something. Reduce file coordination and file-system related errors. Reduce overall tax on the system for existing.
+
+Gaurenteed: This is the cover all case. If the fallbacks are not gaurenteed then the basic promise of PLAYING on request is violated. This does not mean they cannot be changed. It means that the process for changing it should be CERTAIN and TESTABLE to the level of importance that houseads actually runs.
+
+Unattached to a schedule: Reduces human error. Reduces coordination and code path to playing. This allows us to skip any database approach which protects us from a bad DB and file corruption.
+
+The most reliable way to do this is to bake single-file JSON ads into the apk when you build it and let the app choose at random between them. This isn't the ONLY way, just the most reliable. This is not a tool for marketing, this is not a way to get fun things displayed on the TV. those are both tasks for different apps and processes. Defaults of creating an ad and adding it to a global schedule are a separate concept from fallback ads. "Global Default" ads are a tool for marketing. Fallback ads are a gaurentee to devs and other apps that it will meet it's mininum requirements. Yes, I feel strongly about it, so yeah I'm being preachy. If i write it here then it's technically part of design documentation and you can quote this and say "idk man, that's explicitly against design."
 
-## Missing Ticket links
-TBD