Skip to content
Kryshara

Pharos by Kryshara

Programme, financial and timesheet delivery for regulated pharma.

Every programme, project and task tracked end to end, with the budget, the forecast and the hours on the same record, and a history that stands up to an inspection rather than to a stand-up.

on-premise · your data centre
Pharos project list showing an ANDA programme with GxP class and as-of-date filter

The problem

Six things that go wrong, and how long it takes to notice

4 weeks

A month of silent overrun

A project is 40% through its budget and 20% through its work. Nobody sees it until the month-end pack, four weeks after the curves crossed.

2–6 weeks

A gate that slips on evidence

The decision is ready. The stability data, the QA sign-off and the client approval are in three inboxes, and the gate waits for somebody to find them.

Every cycle

Timesheets you cannot reconcile

Hours arrive late and get corrected in place. By invoicing, nobody can show which booked hour became which invoice line.

1 day a week

The Monday spreadsheet

Portfolio status is rebuilt by hand each week from six exports. It is stale before the meeting ends, and no two versions agree.

Every quarter

Resourcing decided in the room

The capacity gap is real but invisible, so allocation is argued rather than calculated, and the bottleneck is found after the commitment is made.

3 weeks

“What changed, when, and who approved it?”

The auditor asks. The answer is assembled from email, file shares and memory, by the people who should be running the programme.

None of these is a reporting problem. They are all the same problem: the plan, the money and the hours live in different systems, and none of them keeps its own history.

What Pharos is

The plan, the money and the hours are one record, and every version of it survives being asked about.

Project management

Programme, project, task and optional subtask. Stage-gate lifecycle, deliverables, scheduling, computed progress and health, with every version of every record reconstructable as of any date.

Budgeting

Versioned budgets with immutable baselines, a cost ledger carrying commitments and accruals, and change orders that create a new baseline rather than editing the old one.

Forecasting

Earned value, spend curves, revenue from backlog, FTE commitments, capacity gap and scenarios, read from the same ledger finance invoices from.

Timesheeting

Configurable periods, activity codes, approval chains, period close and lock, correction by reversal rather than edit, and vendor reconciliation against work orders.

Under all four sits the GxP layer: a hash-chained audit trail, signatures bound to the exact content signed, reason codes on every significant transition, retention and legal hold. It is the reason the first four hold up.

Deliver

Delivery identities that survive being asked about later

Real pharmaceutical work, not generic tickets: an ANDA programme, a media-fill validation, confirmatory nitrosamine testing, a Grade A/B cleanroom qualification.

Deliver · Programmes and projects

State is reconstructed, not remembered

  • Programme, project, task and optional subtask, with progress that rolls up by weighted effort, deliverables or assessment
  • Every project carries its GxP class, which decides the controls, signatures and retention that apply
  • “Show state as of” is a filter on the list, not a report you request
  • Import and export to Excel from the same toolbar, because bulk is how a portfolio arrives
pharos · on-premise
Project detail with version history and the reason each version exists

Deliver · Stage gates

A gate holds until the evidence exists, not until someone remembers

Seeded stage templates for generics development and for CDMO programmes, from molecule selection through exhibit batches, bioequivalence, stability, filing and tech transfer. All of it is tenant configuration, versioned and effective-dated.

  • Gate criteria, required evidence and the approving role are configured per stage template
  • A decision records the criteria as they stood that day, the evidence attached, the reason code and the approver's authority
  • Critical-path scheduling, immutable baselines and computed health across schedule, spend, quality and resourcing
pharos · on-premise
Task list with critical path indicators

Deliver · The board

A move a card may not make is named before you try it

  • Every column, label and drop target comes from your configuration, not a fixed set
  • Destinations a card cannot reach are listed with the workflow's own reason
  • A permitted move still captures a coded reason from your vocabulary before it commits
  • A transition you may not take tells you which roles may
pharos · on-premise
Delivery board listing the moves a card is not permitted to make

Deliver · Governed change

Nothing is ever cascaded silently

  • Archiving has a stated outcome for each dependent record family: block, cascade or leave as is
  • The dialog shows the impact before anything is committed
  • Booked hours stay as they are, because a posting records a fact that remains true
  • A reason is required and recorded against the audit entry
pharos · on-premise
Archive impact dialog showing what blocks and what is kept

Pharma core

The vocabulary of generics, CDMO and CRO work

Pharos models the things a development and manufacturing organisation actually tracks. It integrates with your eCTD publisher, LIMS, MES, QMS and ERP. It does not try to replace them.

Pharma core · Sites and approvalsPharma moat

“Is this site approved?” always names what for

  • Site operations are effective-dated: who operates what, where, and under which approvals
  • Ask about a market, a dosage form or an operation, and the answer names the approval that covers it and its restrictions
  • Sites carry roles such as R&D, API manufacture, drug product manufacture, packaging, testing, stability storage and release
  • Corrections, archives and restores are governed requests, not edits
pharos · on-premise
Site operation with approval check by operation, product category and country

Pharma core · Products and filingsPharma moat

Substances, products, markets and the filings that connect them

  • Development: product–market filings, formulation, analytical methods and validation, exhibit batches, bioequivalence studies, stability studies with pull schedules, and tech transfers
  • Manufacturing: batches, PPQ campaigns, deviations, change control, equipment qualification and controlled areas
  • Regulatory: submissions, CTD sections, agency queries with ageing, post-approval commitments, registrations and renewals
  • Market-specific submission vocabulary is your reference data, not a fixed list
pharos · on-premise
Substance master with governed identifiers

Works with your estate

Pharos integrates with the systems of record you already run, and states its boundary with each.

  • eCTD publisher and gateway
  • LIMS and CDS
  • MES and EBR
  • QMS
  • ERP and general ledger
  • HR system (Helix)
  • Document management
  • Serialization

The money

Where the money actually is, not where it was invoiced

A ledger showing only invoiced actuals can report a project as 43% spent when, with commitments and accruals, it is 82% consumed. That second number is the one a programme director needs in week three.

Financials · As of any date

A baseline is never edited. It is superseded, and both survive.

  • Every financially significant field is append-only, effective-dated history, and every read accepts an as-of date
  • A change order creates a new baseline with its approver, date and reason, so variance is measured against the baseline in force
  • “What did we approve in March?” is answered in seconds, not in a reconciliation project
  • An approved budget version is immutable, and its approval is an electronic signature bound to every line beneath it
pharos · on-premise
Agreement value read as of two different dates

Financials · Cost ledger and rates

The ledger is append-only in the database, not by convention

  • No role can change a posted line. Corrections are reversals that cite the original's exchange conversion
  • Commitments, accruals and actuals in one ledger, with exactly-once posting enforced by database keys
  • The rate in force on the date is the one applied, never the newest one, with a rate resolution trace
  • Earned value, spend curves, estimate at completion and scenarios, computed from the ledger itself
pharos · on-premise
Exchange rate resolved as of a historical date

Time & resource

Hours booked to the work, in the vocabulary you use

Timesheets that finance can invoice from and an auditor can read, because a correction never erases what was there.

Time · Timesheets

Submit, approve, close, lock. Reopening is its own event.

  • Configurable periods and approval chains: line manager, project manager, finance
  • Draft hours change freely, approved hours change only by reversal, and a locked period admits no change by anyone
  • The rate is frozen onto the booking when it is written, and never looked up again
  • Approving a timesheet can be a Part 11 signature that binds to every hour in it
  • Vendor timesheets reconcile in a three-way match against work orders and invoices
pharos · on-premise
Activity code vocabulary with billable and cost category mapping

Time · Resourcing

Allocation calculated, not argued

  • Allocations, capacity plans and a capacity gap that shows the short quarter before the commitment is made
  • Physical resources such as labs, reactors and instruments are plannable alongside people
  • Participation changes need an effective date and a reason code. There is no silent toggle and no delete
  • With Helix, the workforce is entered once: Helix owns employment, Pharos owns participation
pharos · on-premise
Resource profile showing the boundary between participation and employment

Foundation

Master data that is governed, not just stored

Sites, vendors, clients, laboratories and authorities are roles of parties and places, not seven parallel tables that drift apart.

Configure · Master data

Stewardship is a queue with an owner, not a mailbox

  • Maker and checker on governed masters, with self-approval refused by the product
  • Duplicates are evidence-led work: only an independently approved merge retires an identity
  • Controlled vocabularies, custom fields and tenant terminology are configuration
  • Configuration packages promote changes between environments with a qualification record
pharos · on-premise
Master data hub with stewardship queues

Configure · Migration

Bulk import raises change requests. It does not write master data.

  • Preview, validate, then commit through the same approval route as a manual change
  • Idempotent replay, and conflicts open a case rather than overwrite
  • A reconciliation workbench compares sources side by side before anything merges
pharos · on-premise
Governed bulk import with preview and validation

The moat

Why a signature here means something a project tool cannot offer

A signature in Pharos attests to specific content, by a specific verified person, and any subsequent change is detectable.

Guarantee 01

The trail cannot be edited

Append-only at the application, in database roles, and in triggers that refuse updates and deletes, including for the table owner.

Guarantee 02

A signature binds to content

It attests to the exact bytes signed, not to a row that can later change underneath it.

Guarantee 03

Any later change is detectable

Hash chaining and signed checkpoints mean tampering breaks verification.

Guarantee 04

Every significant change has a reason

Reason codes come from your governed vocabulary and are scoped to the kind of change.

Govern · Electronic signaturesPharma moat

A real signing ceremony, not a checkbox

  • Designed to 21 CFR Part 11: two identification components, with the signer re-typing their identifier
  • The signature binds to a hash of the record's content, so it cannot be transferred to an edited version
  • The signer is shown exactly what they are signing and what the signature asserts
  • Bulk approval is deliberately not offered. One request is one signing act
pharos · on-premise
Electronic signature dialog showing what is being signed and its meaning

Govern · Signing authorityPharma moat

A refusal is the evidence

An approval that nobody has watched refuse is one that nobody knows works.

  • Self-approval is refused by the product, on every governed master, rate and agreement type
  • Authority limits apply, and an override is a register entry rather than a quiet exception
  • The register answers the question an auditor asks in the first hour: show me every time you overrode
pharos · on-premise
Self-approval refused with the reason stated

Govern · Reason codes and audit trailPharma moat

Every significant change has a reason, and the trail cannot be edited

  • The business change, the chain sequence, the audit event and the record snapshot commit in one database transaction, or none do
  • A hash-chained, append-only audit trail with chain verification and signed checkpoints
  • Which transitions need a coded reason, and which need a signature, is your decision per record type
  • Audit-trail review, access reviews, retention and legal hold are scheduled work with owners
pharos · on-premise
Reason requirements configured per record type and transition

Govern · PrivacyPharma moat

Every personal-data field declared, field by field

  • A live record of processing: category, purpose, lawful basis, retention and processors for each field
  • Masking policy with audited unmasking, including audited refusals
  • Validation artefacts produced per release: requirements, traceability matrix, and IQ and OQ evidence
pharos · on-premise
Privacy register listing personal-data fields and their treatment

Where it is today

Where the product actually is, and what is next

We would rather tell you than have you find out in a pilot.

Built and proved

Foundation, delivery and stage gates

Tenant isolation, identity, hash-chained audit, master data, programmes, projects, tasks, boards, stage gates and gate decisions.

Built and proved

Budgeting, cost ledger and forecasting

Versioned budgets, immutable baselines, commitments, accruals, earned value and estimate at completion.

Built and proved

Time, approval and signature

Periods, approval chains, locks, correction by reversal and signed approvals.

Built and proved

Pharma core

Submissions, agency queries, filing readiness, batches, stability, analytical methods, tech transfer, assets and approved sources.

In delivery

Operator workspaces

The screens for the pharma core modules. They are backend-complete, and their workspaces are the current work.

Next

Commercial close

Invoicing and billing proposals, vendor reconciliation and three-way match against work orders.

Continuous

Validation

IQ and OQ artefacts, traceability matrix and validation summary, produced per release.

Run the portfolio on the same record the auditor will read.

Start with a working session on your programmes, your gates and your period rules. Then we shape phase one together: scope, environments and validation plan.