Who sees what in a house

Available now A house is a shared bus: its connections exchange payloads. What

the gateway decided about each connection's messages stays with the organisation that owns the app. Every page of the portal applies the same rules, per connection.

The rules

Who	Sees	Doesn't see
The vendor	Its own connections' decisions in full, in every house it's in, with the rule behind every refusal; the payloads its own consumer connections receive; its own credentials	Other vendors' decisions; the publisher's own apps' decisions
The publisher	Everything of its own apps; every accepted message's payload in its story timeline; counts per vendor connection: accepted, refused, failed and duplicate messages, and when each was last seen; what each vendor connection asked for and was granted	A vendor's rule ids, refused messages, paths and credentials (a results statement the vendor shares shows its test results, not these); anything in the vendor's own workspace
Other vendors in the house	Payloads of the messages their consumers are granted	Each other's decisions and credentials
HyperContent	Metadata: outcomes, counts and rule ids. Under the house's support access, also what the house's own viewers see, payloads included, read-only	Payloads, unless an owner of the house grants support access; a vendor's refused messages and credentials, and anything in a vendor's own workspace, even then

Page by page, in a house

What the publisher's members see on each page of the house:

Page	The publisher's own apps	A vendor's connection
Overview	Counts, and the top rejection rules	Counts per connection and when it was last seen, marked "counts only"
Activity	Every decision, with its rules	Counts per connection only, below the list
Story timeline	Accepted messages and refusals, with their rules	Accepted messages (a shared bus); refusals counted per connection
Apps and credentials	Apps, grants and credentials	App, organisation, status and the grants you gave: never its credential
Consumer connections	Queues, depths, credentials and actions	App, organisation, status, grants and queue names; that a replay or redrive happened, when, its range or count and how it ended: never its depths, credential, messages or who made it
First steps checklist	Counts toward the checklist	Never counts toward it. Nor do rehearsal, stand-in and demo newsroom messages
Your house: vendors	—	Invitations, vendors, requests, grants and status: never who at the vendor acted
Your house: skills	Your configured instances and their values, and each one's history	Which of its connections runs each one, what it's subscribed to, and which library skills its app declares. The vendor's executor reads the configured instances bound to it, with their values, and no others; not the paused ones, and never their history
Coverage	Its apps' traffic counts and the statements it shares with itself from its workbench	Traffic counts per connection and family, and only the results statements the vendor shared with your organisation: see Reading the coverage matrix
Rehearsal	Every step the rehearsal or a stand-in played, with the bus's verdict and rule	The part its connection played: counts of accepted, refused and duplicate messages in its step's window, never its rules or messages
Notification emails	Sent about your own connections	Counts only: it went silent, came back, or too many of its messages were refused (vendor connection emails), never which rules

What the vendor sees, from its own vendor workspace, on Houses you're in: its connections in each house, what it asked for and was granted, their credentials, its replays and redrives, and Your activity here: its own decisions in full. On Where your skills run, the vendor sees each of your configured instances bound to its executors: label, skill, version, status and when bound, never the values or your authority scale. Its vendor workspace also gets notification emails about its own connections in the house, with the rules behind its refusals: never about anyone else's.

HyperContent's demo house

Vendors can join HyperContent's shared demo house, Meridian News (demo house), where the demo newsroom plays synthetic stories. The rules above apply, with these differences:

• Nobody runs it. It has no members: the portal connects a vendor's consumer or skill app as asked, recorded in the vendor's audit log as a grant by the house.
• No vendor publishes there. Producer apps can't connect, so the only messages in it are the demo newsroom's. No vendor's payloads reach another vendor.
• Each vendor sees only its own. On Houses you're in, a vendor sees its own connections and activity there, as in any house, and nothing of the other vendors in it: not their names, apps or connections.

HyperContent support access

Available now An owner of the house can let HyperContent read it for a set time, 7 days

at most, from Support in the portal. While it lasts, HyperContent engineers see the house's pages as one of its viewers does, including the payloads in its story timeline, and can't change anything. The house's consent covers the house's own view only: HyperContent's pages show a vendor's connections as counts, as the house's do, and nothing of a vendor's own workspace is included. Every page HyperContent opens is recorded in the house's audit log, and the house's owners are emailed when access starts and when it ends. See Support.

The audit log

Joining, requests, grants, credentials, the start of a replay or redrive, and disconnections are recorded in both organisations' audit logs. The house's log names the vendor organisation for what the vendor did, never its people or their IP addresses; the vendor's own log has the full record, and the same the other way round.

When a vendor leaves

The publisher keeps seeing the counts of the vendor's past connections until they age out of its 7-day views. The vendor's connections there are disconnected, and the house is no longer listed on its Houses you're in page.