Source history should preserve intent as well as files.
Safire Source Vault and Team Vault are being developed as first-class parts of the development environment: source history, developer identity, permissions, collaboration, QA and lifecycle provenance.
Know what changed — and eventually why.
Traditional source control answers the essential question “what changed?”. Safire can connect that change to the wider development work around it.
CustomerCode changed 20 → 12 Reason: Warehouse interchange format supports a maximum 12-character identifier. Task: ERP-184 Affected artefacts: 4 Tests: 3 PASS Release: 4.8
One developer identity across the lifecycle.
Team participants should use the same persistent Safire Developer Identity/Profile across IDE, Vault, tasks, testing/QA, audit and future time/activity tracking.
Identity
Persistent developer, partner, AI-agent and QA identities.
Roles
Administrator, Developer, QA, Designer, Tester, Reviewer, Release Manager and more.
Permissions
Policy at Vault, solution, project and individual .sf source-unit levels.
Audit
Trace development activity, approvals, tests and lifecycle history.
Read, edit, checkout, compile and test are separate capabilities.
The same policy model can govern who may change source while still allowing authorised participants to read, import, compile or test the project.
- Vault-level access.
- Solution-level access.
- Project-level access.
- Individual Safire source-unit access.
- Exclusive checkout where policy requires it.
- Partial check-in and logical artefact versioning.
QA / Tester
May read project source and metadata, build approved targets, execute tests and record QA results — without necessarily receiving source-edit or checkpoint rights.
Explicit trust, not network proximity.
Team Vault is being designed around registered developer/machine identities, explicit enrollment and Safire-owned remote communication. IP/address rules can add trust policy but do not replace identity.
Positive enrollment
Incoming connections are explicitly accepted and tied to a registered identity.
Safire protocol
Remote/team communication uses a Safire-owned application protocol over sockets.
Protected transport
Non-loopback communication requires secure transport policy rather than implicit local trust.
Preserve history while keeping current work fast.
Safire’s wider lifecycle services follow an append-only/data-retentive philosophy: immutable history plus current-state projections, bounded queries, indexing and retention tiers rather than destructive cleanup.
Hot
Current working state and high-frequency access.
Warm
Recent history and operational audit.
Cold
Long-term retained history and archival data.
Source management belongs inside development.
History, identity, permissions, tasks, tests, QA and releases should describe one coherent lifecycle.