Share intentionally.
Your Pulsar Profile is the information surface another person receives. Keep that surface deliberate rather than exposing more than the introduction needs.
Trust, explained
Professional identity should be clear enough to inspect.
No decorative security theatre. Pulsar should make it understandable what you share, what can change, and where company control begins and ends.
Stay editable.
Physical cards and QR codes point to a live destination. The identity can evolve without forcing every older introduction to become obsolete.
Keep roles understandable.
In a team deployment, separate organisation-level content from person-level identity so control is explicit instead of ambiguous.
Explain before claiming.
Privacy, security and compliance language should map to actual implementation and documented controls—not invented badges.
Identity architecture
What another person sees should be a choice, not an accident.
Think of the profile as a deliberate public layer. Keep internal notes and relationship context separate from what you publish outward.
PUBLIC LAYERPulsar ProfileName · role · links · actions you choose to publish
separate context
RELATIONSHIP LAYERNotes + meeting contextInformation used to remember the relationship rather than present the public identity
Before launch
Connect claims to the real deployment.
This website deliberately avoids claiming certifications or security guarantees that are not documented here.
Does this page claim Pulsar is certified to a specific standard?+
No. Certification claims should only be added when a current, verifiable certification and scope are available.
What information does an NFC tap reveal?+
The physical card is designed to open the Pulsar destination. The exact technical payload and production configuration should be documented alongside the deployed card encoding process.
Can the profile be updated after the card is issued?+
Yes. The live-profile model is specifically designed so the information behind the persistent destination can remain current.
How should team permissions be described?+
Only describe permissions that the production admin system actually enforces. Marketing copy should match the deployed role model exactly.