Developers

Build with PTR

The PTR API and SDK are a product, arranged under an enterprise agreement, so the way in is a conversation rather than a signup form.

Request API and SDK access Governance and data locations

The moment

A member portal, a support desk that closes at six, and a board asking where the AI is

A product lead at a health fund ships a member portal her team built. She wants a twin that answers from the fund’s own policies inside that portal, opened from her own button, with every conversation recorded against the page it started on. What she does not want is a chatbot bolted on beside it.

A man stands in a dark studio with a stack of message panels on one side of him and a ribbon of sound on the other. — Your users get the same twin whether they type or speak, from the surface you already ship.

A woman stands in a dark studio beside a rising stack of blank message panels, mid-sentence. — Your conversation opens in writing on your page, and records which page it started from.

Two designers compare abstract character shapes onscreen. An AI roleplay scenario for digital twins. — Your product team settles the persona and its boundaries before a line of integration code.

The agreement

What the agreement provides

Access to the PTR API and SDK is granted under an enterprise agreement, arranged through the contact form. Where a build touches a real person’s likeness or voice, consent and oversight are settled in the agreement, the same position the digital twins page takes. Hosting for the application and its database is recorded as deployed in an Australian region in the Subprocessors and Data Locations register; the governance page is the reviewer-facing version.

A practitioner draws two controls inward and the translucent boundaries around an AI station contract. An AI roleplay scenario for applied AI in sensitive conversations. — You set the boundaries the twin answers inside, and tighten them without a redeploy.

Two colleagues review blank tokens for AI safety. An AI roleplay scenario for custom AI experiences. — Your safety reviewers see what the twin may and may not say before your members do.

The twin hands over to a human adviser. A first person AI roleplay scenario for applied AI in sensitive conversations. — Your member is handed to a human adviser the moment the twin reaches its limit.

Request API and SDK access Governance and data locations

Building on PTR for your organisation?

Open the contact form

Open on this site

The parts that need no agreement at all

The twin widget and the machine-readable copies of the site are served to anyone. They are the fastest way to see the shape of the thing before a conversation about the rest.

A tall stack of blank message panels rises and recedes into the dark, with nobody in the frame. — Your visitors read the conversation as a stack of panels, on any page you place the element.

Two colleagues test an AI build in an open office, a response panel floating between them. A rapid prototyping scenario for fast builds. — Your team tests the twin in your own office, with the response panel between two colleagues.

Two people beside floating abstract shapes, one holding the answer given and one the intended flow. A first person AI roleplay scenario for applied AI in sensitive conversations, seen through the headset. — Your reviewers hold the answer given beside the flow you intended, and correct the gap.

A man stands in a dark studio behind a wall of glowing message panels, reading the conversation from the other side. — Your visitors open the twin from your own page; the markup below is the markup in the bytes you are reading.

The twin widget, as a custom element

A script tag and an element. Set twin to the twin’s name and source to a short label for your page, so each conversation records where it was opened.

Load the script once, in your page’s head or just before the closing </body> tag.
Place the <ptr-digital-twin> element where the twin should open from.
Set twin to the twin’s name and source to a short label for your page, so each conversation records where it was opened.

HTMLPaste into your page

<script src="https://ptr-digital-twin-widget.web.app/ptr-digital-twin.js" defer></script>
<ptr-digital-twin twin="simon" source="corporate"></ptr-digital-twin>

twin names the twin and source names the surface it was opened from; the loader that mounts it here is public/Didymo.dc.html, readable in this page’s own source.

A woman in a plain room reaches toward a floating notes panel, a doorway open behind her onto a courtyard of grey blocks. A rapid prototyping scenario for fast builds. — Your button stays your button: one window event opens the rail or a specific panel.

Opening a rail from your own interface

Window events drive it. This site’s own navigation dispatches didymo-toggle, and other pages dispatch didymo-open for a specific action: chat, voice, avatar or book.

Load the twin widget as in the sample above.
Choose one of the two samples below and put it in your button’s click handler. Use one per button, not both.

JavaScriptOption A: open a specific panel

window.dispatchEvent(new CustomEvent('didymo-open', { detail: { action: 'chat' } }));

JavaScriptOption B: open or close the rail, no panel chosen

window.dispatchEvent(new CustomEvent('didymo-toggle'));

An event with no detail opens the rail rather than a specific panel; the shipped widget answers the URL hashes #didymo and #didymo-chat the same way.

Blank glass cards float in a ring around a bright core in a dark studio, with nobody in the frame. — Your agent fetches the words of every page from fixed addresses, without parsing the markup.

A site an agent can read without parsing it

Each route is published as HTML, as a Markdown alternate at the same path, and inside a whole-site digest. The Markdown is an alternate representation rather than a second canonical page, so it is linked from the head and kept out of the sitemap.

Fetch /llms.txt for the list of routes.
Fetch /llms-full.txt when you want every page’s words in one file.
For a single page, follow the Markdown alternate linked from its head.

URLsFetch these addresses

https://peopletechrevolution.com/llms.txt        the route catalogue
https://peopletechrevolution.com/llms-full.txt   every page's words, combined
https://peopletechrevolution.com/sitemap.xml     the indexable documents

<link rel="alternate" type="text/markdown" href="https://peopletechrevolution.com/developers.md">

The structured data on each page is a JSON-LD @graph; a tool in the repository submits changed routes to IndexNow.

A figure made of light passes a set of glowing panels to a woman stepping into the frame in a dark studio. — Your reviewer pins the exact text they assessed by its version and checksum.

A legal library with a checksum

The privacy policy and the terms are versioned documents, and the build carries a manifest of them: a document identifier, a version, an effective date, a SHA-256 of the text and its canonical address. The documents live at legal.peopletechrevolution.com, and a new version replaces the old one at the same address.

JSONShape of one manifest entry. For reference, values left out

"PTR-PRIVACY": {
  "version":        "...",
  "sha256":         "...",
  "effective_date": "...",
  "title":          "People Tech Revolution Privacy Policy",
  "canonical_url":  "https://legal.peopletechrevolution.com/privacy"
}

How this site is built

The engineering underneath, in specifics

The decisions a developer evaluating an integration asks about, each visible in the bytes this site already serves.

One vertical slice of a build reviewed on a laptop, the whole path working end to end. — Your review starts with one vertical slice working end to end, not a slide about one.

A web wireframe taking shape on screen, a rapid prototyping scenario for fast builds. — Your wireframe becomes a served page early, so the hosting behaviour is tested with it.

A tablet build passed across a workshop table. — Your build is passed across the table on the device your users carry.

A web build on two screens: what the customer sees, and the page behind it. — Your crawler, and your reader with scripting off, gets the whole page from the server.

Static hosting, and a page that reads with scripting off

Static files behind a hosting edge. Every route whose text is produced at runtime also ships a fallback captured from a real browser, removed in the same frame the runtime mounts the live tree. The marker around it carries a SHA-256 of the component template, its imports and their shared inputs, so a stale capture fails the build’s own check.

HTMLSimplified page structure. For reference

<body>
  <div data-prerender-static>
    ... the whole page, exactly as Chrome rendered it ...
  </div>
  <x-dc><template> ... the live component ... </template></x-dc>
</body>

Grep any route on this domain for data-prerender-static and it is there in the served bytes, bracketed by the marker described above.

Copy the command for your system.
Run it in a terminal.
A count above zero means the fallback is in the page the server sent.

BashmacOS or Linux terminal

curl -s https://peopletechrevolution.com/developers | grep -c "data-prerender-static"

PowerShellWindows PowerShell

(curl.exe -s https://peopletechrevolution.com/developers | Select-String -Pattern 'data-prerender-static' -AllMatches).Matches.Count

Objects rest beneath a streetlight, seen through the headset. — Your sub-path build resolves its own modules, because the trap below is named in the head.

Panoramas, and the trap that sits under them

The 360 viewer reads its scenes from a manifest, mounts its renderer on the click that opens it rather than on page load, and pushes a history entry so the hardware back gesture closes the viewer instead of leaving the page. A clean URL served with no trailing slash resolves relative paths against the parent directory, so lib/app.js is fetched from one directory up; naming the document’s own directory in the head removes that failure.

Specifications

What we build against

Open specifications, each linked to its own publisher so a reviewer can read the source rather than our summary of it.

Light and dust fill a virtual museum hall, seen through the headset.

WebXR Device API. The browser standard your immersive session enters through; it requires a secure origin, which shapes how a headset-capable build is served.

glTF and VRM. Your characters travel as Khronos glTF, the transmission format for real-time 3D, with VRM as the humanoid avatar profile on top of it.

A professional arranges boundary rings on a workbench.

Schema.org and JSON-LD. Your search result gets a graph generated by a tool and checked by a gate, rather than hand-written per page.

For readers and agents

What a reader, or an agent, gets without asking

The words of every page at fixed addresses, and a front end written against the accessibility guidelines, with focus and reduced motion handled.

Colleagues at a bench sort blank cards, monitors in the background.

The llms.txt convention. Your agent gets a route catalogue and a whole-site digest at fixed paths, the words rather than the markup.

A wheelchair user compares access methods.

Web Content Accessibility Guidelines. Your keyboard user finds the contact dialog traps focus while open and hands it back afterwards; a reduced-motion preference stops the looping clips.

Two colleagues test a connected task. An AI roleplay scenario for digital twins. — Your twin or scenario sits inside the product you already run, tested as one connected task.

Tell us what you would build

Say what your product does, who your users are, and where a PTR twin or scenario would sit inside it. A custom build shapes the rest around your own knowledge; the AI overview shows the pieces.

Request API and SDK access Governance and data locations

Building on PTR for your organisation?

Open the contact form